Before really starting to optimize the performance of J2EE application, everyone tries to identify the areas which is causing the performance reduction.
Here is what I feel one should look at for identifying the problem areas
There will be all the way four sources of performance problems in J2EE applications:
* The application code (Back-end or GUI)
* The environment upon which the application is running (application server, JVM, pperating system, network, etc.)
* External dependencies (database, legacy system, Web service, native server, etc.)
* Excessive load
By identifying these four facets of performance problems, we can better formulate a plan to analyze the root-cause(s) of performance problems,
and then develop a resolution plan.
To summarize these four performance facets:
1. The problem can be in the application itself :
There can problem with application code. I am giving some examples but these are not all, there can be more.
excessive object creations, inefficient loops and iterations, more database stuff in code, GUI code problems....a big list.
2. The configuration of the environment:
The environment in which the application is running. This basically covers the application server configuration.
Considering four major parameters are well configured in application server, you are 80% done of the performance optimization.
Heap configuration - For garbage collection stuff.
Thread pools - If you do not have a thread to serve an incoming request, the tuning won't matter, because the request will be queued up waiting to be processed.
Database connection pools - If you do not have enough database connections in your pools, requests will process as far as they can...
and then wait for a database connection, introducing a new bottleneck.
Entity Bean cache - If cache is too small, the overhead to maintain the cache will overpower the benefit you receive by using it;
and if it is too large, you are unnecessarily using too much heap!
3.Something upon which the application depends.
This area covers the other systems like database, web service, legacy system, etc. Note:A database configuaration optimization can improve the application performance dramatically.
4. Excessive load : If there is excessive load on the application than expected, for which it was designed.
If it is none of the above, then the environment has reached its capacity and it's time to add hardware.
Note that throwing hardware at a problem is the last choice, not the first!
Showing posts with label Performance. Show all posts
Showing posts with label Performance. Show all posts
Wednesday, December 30, 2009
Thursday, April 30, 2009
Measure your application's size in memory
We should not generally prefer to construct the application and then workaround the performance issues.
Measuring performance throughout construction can help to identify major performance problems as quickly as possible, which is almost always beneficial.
If a major problem becomes apparent, then some immediate redesign will likely be necessary.
If no major problem is apparent, then, if needed, minor optimizations can be performed later, when construction is nearly complete.
(Many would argue that worrying about minor optimizations during construction is not advisable, since optimizations can sometimes make code more obscure.)
But fixing this minor optimizations can also be very useful to avoid the major issues later.
The excellent JConsole tool comes with JSE 6, and can be used to manage and monitor a local or remote Java Virtual Machine.
If JConsole is not available, there are some other means of measuring an application's size in memory. They depend on your platform. For example:
* NT : Task Manager, look for java.exe or javaw.exe
* Unix : get the process id "ps -e | grep java", pass it to pmap, as in "pmap -x 6598", and look for total KB entry in the Private column
As well, the JDK itself comes with basic profiling tools. For example :
* Runtime.freeMemory()
* Runtime.totalMemory()
* java -Xprof MyClass
* java -Xrunhprof:[options] MyClass
Measuring performance throughout construction can help to identify major performance problems as quickly as possible, which is almost always beneficial.
If a major problem becomes apparent, then some immediate redesign will likely be necessary.
If no major problem is apparent, then, if needed, minor optimizations can be performed later, when construction is nearly complete.
(Many would argue that worrying about minor optimizations during construction is not advisable, since optimizations can sometimes make code more obscure.)
But fixing this minor optimizations can also be very useful to avoid the major issues later.
The excellent JConsole tool comes with JSE 6, and can be used to manage and monitor a local or remote Java Virtual Machine.
If JConsole is not available, there are some other means of measuring an application's size in memory. They depend on your platform. For example:
* NT : Task Manager, look for java.exe or javaw.exe
* Unix : get the process id "ps -e | grep java", pass it to pmap, as in "pmap -x 6598", and look for total KB entry in the Private column
As well, the JDK itself comes with basic profiling tools. For example :
* Runtime.freeMemory()
* Runtime.totalMemory()
* java -Xprof MyClass
* java -Xrunhprof:[options] MyClass
Monday, April 20, 2009
Do not synchronize doGet, doPost
The servlet specification strongly recommends that doGet, doPost, and all other service methods should not be declared as synchronized.
Declaring such methods as synchronized will often decrease performance significantly.
It is not necessary to declare these methods as synchronized at all, since this is taken care of by the servlet container itself.
Declaring such methods as synchronized will often decrease performance significantly.
It is not necessary to declare these methods as synchronized at all, since this is taken care of by the servlet container itself.
Subscribe to:
Posts (Atom)