This content has been marked as final. Show 2 replies
The list is quite long but finds below the most critical performance items you should monitor during your load test exercise:
## Physical server and OS related
- CPU utilization
- Physical memory
- Disk performance and paging activity
- Java process memory size of your 64-bit VM (also important to monitor C Heap size of your Java process, check for any native memory leak over time etc.) and look at your physical RAM requirement per Java process under peak load
- Java Heap utilization / footprint
- PermGen space utilization / footprint (if using HotSpot VM)
- Native memory / C Heap utilization (monitoring technique will depend of your OS)
- Garbage collection performance/elapsed time/frequency etc.
## Weblogic side
- Threads utilization
- JDBC Data Source utilization and leak verification (if applicable)
- HttpSession utilization (if applicable)
- EJB/MDB pool bean utilization (if applicable)
- JMS queue utilization (if applicable)
- Cluster performance e.g. look for any packet loss etc. (if applicable)
- Socket / File Descriptor utilization (via netstat / lsof commands)
## Other recommendations
- A few Thread Dump snapshots should be captured during peak load and analysed; especially if high thread utilization is observed
- Heap Dump could be generated before, during and after load test in order to understand your application Java Heap footprint and ensure no leak
- If using Oracle database, AWR reports should be generated during your load test and investigate any SQL contention / tuning opportunity such as sub optimal execution plan, lack of proper indexes etc.
- Negative testing should be added for 1 or 2 load testing cycles in order to simulate TX slowdown and physical downtime of one or many of your downstream system should be done along with timeout validation (ensure no infinite hanging Thread and domino effect)
On top of this, you should track your application business response time and compare between each cycle.
Your load testing strategy should include an initial run to capture a baseline, each tuning or change applied should be then compared to your initial baseline in order to validate any improvement or degradation of any performance figure.