Implement the IBM best practices. This is low hanging fruit and best place sets a baseline.
Analysis: What is slow? When is it slow?
If you make changes without understanding you will spend a lot of time spinning your wheels and possibly make it worse.
Interview users to determine a series of exact steps that are slow and when. Determine if performance can be reproduced in a development system or only in prod (under load). If the performance issues can only be reproduced under load you will need load testing to reproduce issues. Is the application accessed remotely, is the issue only happen remotely or locally as well? Users will often say things like “The entire application is slow” but you need to isolate it more. In one case the users complained Work Order application was slow. Upon initial investigation no performance issues could be found until a route was added. Adding routes with > 1000 assets triggered a series of validations and sql queries. The sql queries alone were very fast but the sum was very slow. At one site there was issues w/ a oob non persistent field on main Workorder tab that was expensive. Identify the use cases, document them with any fields or steps. Put the use cases into an excel sheet so they can be benchmarked later.
Debugging: Why is it slow? What is slow?
After you determine that Workorder App view one is slow all of the time even without load or the entire application is slow remotely you can start to figure out why.
Network or Server?
If a request from click to response is 10s and its spending 9.9s on server and 0.1s on server optimizing network will be a waste of time. Do not proceed until you know if its server or network issue. Use fiddler to obtain benchmarks and determine how much time was spent on server vs network.
The server is slow.
The 10s request took 9.9s on server. The same request takes the same time under load as without load.
Turn on IBM performance monitor. This will help isolate a single request into smaller chunks and determine what code and sql is being executed and the details of the 9.9s.
- many sites have had issues relating to oob ibm code/queries
- benchmark, experiment, repeat. make sure results are repeatable. Track your benchmarks in excel sheet
- analyze sql queries. make sure they are using indexes. rewritten sql queries can be put into relationships
- Fields, tables displayed on particular tab initialize when tab loads, move them off off if possible especially non persistent
- some calculated fields can be persisted at the time they are calculated
- doclinks can be rewritten and persisted
The network is slow
The 10s request spent 9.9s on network
- One client had remote users and network issues. The http server was located in a remote site so gzip was implemented in app server which has a minor server hit.
- Implement gzip on http server or load balancer (f5)
- Ensure the client is caching objects properly w/ fiddler. make sure the max-age is set
The issue can only be reproduced in prod (under load)
- ensure resourced appropriately. 25 concurrent users per ui. bros, mif and ui are separated
- reproduce the load in a dev environment using tools like stress tester
- use the built in operating system, application server tools to do further analysis
- benchmark, tweak, benchmark
- its more common to have configuration than load related issues