Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Aperi Performance Issues using Derby as Repository
When we started testing Aperi code with Apache Derby - 10.1.3.2 database, we noticed some of DB performance issues and had worked with Derby team to open issue DERBY- 1205 to address it. While we are waiting for Derby team to resolve the DERBY - 1205 issue [1], we like to document our findings.
First, I like to describe the initial setup of my test environment. I installed Aperi Servers/Agents code in a single computer, using inband and out of band agent to discover 6 Fabrics, Cimom discovery discovered 5 Subsystems.
The time consuming process started with L0:Fabrics view, it may take up to 4 minutes + to display 6 fabrics - one with 8 switches concatenated together, one Cisco switch fabric with two virtual fabrics and the other two fabrics with single switch.
To display L1:Fabric-fabric view with 8 concatenated switches may also take up to 4 minutes +
L1:Computers-status view is also time consuming. In my test, there is only one computer, yet it may take 2 minutes+ to display it
The L2:Computer-server view may take up to 2 minutes to display it while any other L2 views for switch, subsystem and other take less than 2 minutes to show up in the Topology Viewer
Another area where we noticed the performance issues are in the Aperi report section
The Aperi Storage Manager ->
My Reports->
System Reports->
Fabric->
Port Connections report
with a number of 302 ports may take up to 4 minutes + to display
The Aperi Storage Manager ->
My Reports->
System Reports->
Fabric->
SAN Assets(ALL) report
with a number of 65 rows may take up to 2 minutes to display
The Aperi Storage Manager ->
My Reports->
System Reports->
Fabric->
SAN Assets(connected) report
with a number of 53 rows may take up to 1 minutes+ to display