Large number of JSP performance [repost for grandemange]

Question

Hi,
a colleague of me made tests with a large number of JSP and identified a
performance problem.
I believe I found a solution to his problem. I tested it with WLS 5.1 SP2
and SP3 and MS jview SDK 4.
The issue was related to the duration of the initial call of the nth JSP,
our situation as we are doing site hosting.
The solution is able to perform around 14 initial invocations/s no matter if
the invocation is the first one or the
3000th one and the throughput can go up to 108 JSPs/s when the JSP are
already loaded, the JSPs being the
snoopservlet example copied 3000 times.
The ratio have more interest than the values as the test machine (client and
WLS 5.1) was a 266Mhz laptop.
I repeat the post of Marc on 2/11/2000 as it is an old one:
Hi all,
I'm wondering if any of you has experienced performance issue whendeploying
a lot of JSPs.
I'm running Weblogic 4.51SP4 with performance pack on NT4 and Jdk1.2.2.
I deployed over 3000 JSPs (identical but with a distinct name) on myserver.
I took care to precompile them off-line.
To run my tests I used a servlet selecting randomly one of them and
redirecting the request.
getServletContext().getRequestDispatcher(randomUrl).forward(request,response);
The response-time slow-down dramaticaly as the number of distinct JSPs
invoked is growing.
(up to 100 times the initial response time).
I made some additional tests.
When you set the properties:
weblogic.httpd.servlet.reloadCheckSecs=-1
weblogic.httpd.initArgs.*.jsp=..., pageCheckSeconds=-1, ...
Then the response-time for a new JSP seems linked to a "capacity increase
process" and depends on the number of previously activated JSPs. If you
invoke a previously loaded page the server answers really fast with no
delay.
If you set previous properties to any other value (0 for example) the
response-time remains bad even when you invoke a previously loaded page.SOLUTION DESCRIPTION
Intent
The package described below is design to allow
* Fast invocation even with a large number of pages (which can be the case
with Web Hosting)
* Dynamic update of compiled JSP
Implementation
The current implementation has been tested with JDK 1.1 only and works with
MS SDK 4.0.
It has been tested with WLS 5.1 with service packs 2 and 3.
It should work with most application servers, as its requirements are
limited. It requires
a JSP to be able to invoke a class loader.
Principle
For a fast invocation, it does not support dynamic compilation as described
in the JSP
model.
There is no automatic recognition of modifications. Instead a JSP is made
available to
invalidate pages which must be updated.
We assume pages managed through this package to be declared in
weblogic.properties as
weblogic.httpd.register.*.ocg=ocgLoaderPkg.ocgServlet
This definition means that, when a servlet or JSP with a .ocg extension is
requested, it is
forwarded to the package.
It implies 2 things:
* Regular JSP handling and package based handling can coexist in the same
Application Server
instance.
* It is possible to extend the implementation to support many extensions
with as many
package instances.
The package (ocgLoaderPkg) contains 2 classes:
* ocgServlet, a servlet instantiating JSP objects using a class loader.
* ocgLoader, the class loader itself.
A single class loader object is created.
Both the JSP instances and classes are cached in hashtables.
The invalidation JSP is named jspUpdate.jsp.
To invalidate an JSP, it has simply to remove object and cache entries from
the caches.
ocgServlet
* Lazily creates the class loader.
* Retrieves the target JSP instance from the cache, if possible.
* Otherwise it uses the class loader to retrieve the target JSP class,
create a target JSP
instance and stores it in the cache.
* Forwards the request to the target JSP instance.
ocgLoader
* If the requested class has not the extension ocgServlet is configured to
process, it
behaves as a regular class loader and forwards the request to the parent
or system class
loader.
* Otherwise, it retrieves the class from the cache, if possible.
* Otherwise, it loads the class.
Do you thing it is a good solution?
I believe that solution is faster than standard WLS one, because it is a
very small piece of code but too because:
- my class loader is deterministic, if the file has the right extension I
don't call the classloader hierarchy first
- I don't try supporting jars. It has been one of the hardest design
decision. We definitely need a way to
update a specific page but at the same time someone post us NT could have
problems handling
3000 files in the same directory (it seems he was wrong).
- I don't try to check if a class has been updated. I have to ask for
refresh using a JSP now but it could be an EJB.
- I don't try to check if a source has been updated.
- As I know the number of JSP I can set pretty accurately the initial
capacity of the hashtables I use as caches. I
avoid rehash.
Cheers - Wei

Answer 1

I dont know the upper limit, but I think 80 is too much. I have never used more than 15-20. For Nav attributes, a seperate tables are created which causes the Performance issue as result in new join at query run time. Just ask your business guy, if these can be reduced.One way could be to model these attributes as seperate characteristics. It will certainly help.
Thanks...
Shambhu