Precompiling JSPs for Deployment

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

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

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
> > 
> > 
> 

Re: Precompiling JSPs for Deployment

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

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
> 
>