jb2works.com
>
How to find Bottlenecks
eng
|
de
Java Applications - How to find Bottlenecks
Where is my application hanging now? Why does my program slow down?
Do we have a deadlock? Or a multiuser problem?
This check list is surely not perfect but will help to find your bottleneck:
[ click on activity to get more information ]
The difference between a bottleneck and a performance issue
An application has always one or more bottlenecks which limit the current application performance.
But only if the application is not fast enough for the user then we call it 'Performance Issue'.
In this case and only in this case you should optimize your application. Never put additional effort
in optimizations without you have measured or at least calculated a real benefit.
Check CPU Load
Use a CPU Load monitor (e.g. windows: task monitor, unix: xload, xosview, top).
A CPU load of > 50 % is a bottleneck beside other ones.
A CPU load of 100 % means this is the only bottleneck.
Check Heap Size
Monitor the heap without to force garbage collection: For Java the currently used heap is:
Runtime.totalMemory() - Runtime.freeMemory() . A pending heap of 5% of heap size is normal.
Larger values of pending heap size can be bottlenecks, a continuously growing heap is also critical,
probably a Memory Leak.
If you don't already have a heap size check in your application then simply start your application
with a memory profiler. If you use the Reference Scanner then you find the information
on the start page where you log on.
Diagnosis Too Many Operations
Measure the time between enter/leave a function. Optimize these functions first wherein the application spends
the most time.
To find out the critical functions for smaller things you may use a System.out.println(millis)
but rather you use a CPU profiler.
Another helpful category of tool is a CPU sampler. Such a tool will look periodically
at the function stack and shows how often functions will be found there on top.
So it can estimate which functions are critical.
Check Hard Disk IO
Use a hard disk IO monitor to see whether there are hard disk operations. Or simply listen to your hard disk.
Diagnosis Too many Allocations / Deallocations and Operations
Use a CPU or memory profiler to find out where the time is spent. Check whether the creation
of objects is really necessary. Try to work with less objects, maybe use a object pool.
Check your -Xmx Java VM option because maybe the value is too low.
A higher value reduces the number of gc() runs. The used heap should
be always less than 90% of the -Xmx value.
Diagnosis Swapping / File Operations
Swap operations are always critical. This means the Java VM tries to extend the heap size
by forcing the OS to swap another - probably also needed - process to the hard disk.
If currently needed processes must be swapped by the OS then this will be a periodically repeated operation
for the remaining runtime of these processes and it extremely slows down your application.
If you cannot reduce the number of processes and if you cannot reduce your used Java heap then
you must plug more physical memory in the machine.
File operations are critical if it stops the application main thread for a longer time.
Use a read / write buffer or try to schedule them to a background thread.
Check Network Traffic / Round Trips
Use a network monitor (e.g. unix: xosview) to monitor the network load. If the traffic is
a continuous stream it is useful to know what the real network bandwidth is: Copy
any big file to the server and have a look at the transfer rate. The real network bandwidth is _not_
the value for the maximum bandwidth that your network adapter allows!
Diagnosis Bandwidth Too Low
Firstly check whether it is really necessary to transfer that big amount of information.
Probably there is a lot of redundant data contained in the stream.
If you really need all the data then try to compress. E.g. use a gzip stream.
Another possibility is to increase the network bandwidth. Probably another routing or
clustering of the network resources can already increase the real bandwidth.
Check Wait for Server Response
Use a debugger and stop the application. Check where the application thread does wait.
Maybe a SQL Query or a Http Request?
Diagnosis Too Many Round Trips
An application can waste a lot of time by sending and receiving many small packets.
A typical case is an SQL query with a lot of id's in the result and then in follow up
the application sends a lot of further queries to obtain the record for each id.
Try to optimize for less round trips and more information in the transfered packets.
Maybe do a join or pre-fetching.
Diagnosis Wait for Server Response
Try to optimize the server response time. For SQL queries, create and read the sql trace
file. Optimize the execution plan, restructure the query, use indexes, add hints and rules, whatever.
For Wait on Http responses, maybe a cache on server side or client side can make sense.
Check Wait For Resource
Stop the application with a debugger, check whether the application thread waits
in a deadlock or does simply wait for a resource.
Diagnosis Wait For Resource
Check why the resource is locked, whether it is necessary to lock the resource at all.
If the lock is necessary then try to reduce the wait time for the waiting thread.
If the resource request waits in a deadlock then find out the locked resources on both sides
and resolve the deadlock.
But try to avoid a solution where a copy of a resource will be created because it is
overhead and can have data inconsistence as result.
Diagnosis Thread Suspended
The application thread is suspended and waits for a notify() to wake up or
for the thread simply a thread.sleep(millis) has been called.
| |
|
