You know the symptoms:
JEE Application works okay on Unit Integration and Test servers.
But once you're into Performance and Stress Testing - it's totally choked up - pages are returned so slowly - Project Manager is asking for a code review to find the blockers - etc.
The first thing to do on a slow JEE application is to take a thread dump, see more on that here
Now, the thing to look for in the Thread Dump, is multiple threads doing this:
waiting for monitor entry [c4f7f000..c4f7fc28] at weblogic.servlet.internal.ServletStubImpl.checkForReload(ServletStubImpl.java:771)
This is not a stuck thread within your code – but this is a weblogic.xml setting for checking each time if your servlet class or JSP has been changed.
As documented here:
Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.
If set to 0, pages are checked on every request. If set to -1, page checking and recompiling is disabled.
Most users set this to -1 to disable in Production unless they're altering jsps on the fly (which is not normal practice on a production system).
The correct syntax for this is:
The similar value for servlets is set using the servlet-reload-check-secs within the tags below.
On non-production environments, you can set this to a reasonable value such as 600 (in seconds, which is 10 minutes) to allow for changed JSPs you drop in/FTP to the deployed environment, and want those to reflect sooner.
The other thing we must do on a production system is to precompile the JSPs as part of the build, and before deploying to Live.
Else, even the first time JSP compilation is quite slow and this must be avoided on the Production system.