Slow startup - Was: Precompiling JSPs for Deployment

[Greg <gr...@Brim.Net>]

Okay, here's the deal. I'm using Tomcat 3.2b2, not 3.1 like I thought and
the documentation indicates... Someone needs to update at least the
doc/readme :)

Anyhow, the s-l-o-w startup is due to the new code in
org.apache.tomcat.util.SessionIdGenerator that uses SecureRandom to
generate session ids. SecureRandom under JDK 1.3 for Linux is VERY slow. I
don't know why, since Linux has a /dev/random implementation, but oh well;
maybe Sun'll fix it later.

Well, to fix this problem, I altered SessionIdGenerator. Attached is the
new SessionIdGenerator.java, a diff of the old to the new, and the
SessionIdGenerator.class file for anyone else having this problem... My
code basically checks for Linux and reads from /dev/random if it can. If
not Linux, or it has trouble with /dev/random, it defaults back to
SecureRandom...

Hope this helps someone out other than just me.. :)

Greg Holt



> Okay, more information I've discovered:
> 
> It seems that Tomcat *does* persist the JSPs it compiles in the work
> directory and will use them even after a restart. However, *something*
> that requires major CPU time is running for the first JSP that is hit --
> whether it needs compiling or not.
> 
> Test Proof:
> 
> Run Tomcat straight from distribution. Access the Number Guess JSP. After
> a while, the page is compiled and displayed. Keep an eye on the CPU usage;
> it will stay high for a little while. Once things settle down, access the
> Date JSP. Much more quickly, it will compile and display.
> 
> Now, shutdown Tomcat. Make a backup of the work directory. Restart Tomcat.
> Access the Number Guess JSP again and notice that it *seems* to be
> compiling the page again -- but it isn't really. Once the page loads and
> the CPU returns to normal, access the Date JSP again. Notice that it loads
> instantly with no compile time.
> 
> Shutdown Tomcat again. Compare the new work directory with the backup
> you've made and notice that no files have changed (check dates and times
> since content definitely shouldn't change). This shows that Tomcat did not
> recompile the pages again since it already had done so during a previous
> run. This is great; however....
> 
> What *is* taking so long upon the first JSP hit? Is it loading the
> compiler classes or something? Can this be fixed to only happen when the
> first compilation is required???
> 
> I will keep sifting through the source code for answers...
> 
> 
> Greg Holt
> 
> 
> 
> 
> > Hi,
> > 
> > I'm sure this is probably a FAQ, but I searched through all the FAQs I
> > could locate and couldn't find the answer. The FAQ for this email list is
> > interesting -- it's blank!
> > 
> > Anyway, my question is this: How do I deploy my web app with all JSPs
> > precompiled and still keep the end-user's ability to alter the JSPs and
> > have them recompiled on the fly as they are now?
> > 
> > The main reason for this is that the compile time for a JSP is way too
> > long. I am planning to ship a product with a web based interface using
> > JSPs, Servlets, etc. The end-user will install the product, start the
> > server, and open the browser to it. Then, they have to wait as they click
> > around for the JSPs to compile. Sure, they run nice and quick after the
> > first time, but the first impression that my product gives is s-l-o-w, and
> > most of these users are not ones that understand what JSP is.
> > 
> > I know you can use the JSPC to precompile all the JSPs into Servlets. But
> > this seems to prevent the on-the-fly altering of JSPs that some end users
> > will want to do. Why not just make them Servlets to begin with?  
> > 
> > As an alternative, I tried to see if I could figure out how Tomcat is
> > caching these compiled JSPs and see if I could "persist" them. I know that
> > it is putting them all in the "work" directoy. But it seems to start from
> > scratch at each startup. If I could get these to persist, I could at least
> > run Tomcat, hit all the JSPs myself, and then package that up "pre-run".
> > 
> > Greg Holt
> > 
> > 
>