Skip to main content

Compiling JSP is slow on v3

29 replies [Last post]
nielzw
Offline
Joined: 2009-12-21

Upgraded from v2 to v3
After each deploy, JSPs are compiled on request. This is much slower on v3.
The Precompile option in admin delays the deployment to 20 minutes.
Compiling all JSPs in NetBeans occurs within 4 seconds.

Is there something I can do to get v2 compile performance on v3?

--- A few days later:

I downgraded to Tomcat 6. It is so much faster. This is a webapp with about 30 jsp files. Nearly every night a new version gets deployed. There are a two users that start early in the morning and they struggle through the pages to get compiled. With Tomcat 6 they do not notice the JSP compile time.

If someone can tell me how to make v3 as fast as Tomcat 6, I will 'upgrade' again.

Message was edited by: nielzw

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Craig Ringer

On 9/09/2010 8:46 AM, glassfish@javadesktop.org wrote:

> I'll need figure a way to not to hardcode the specific jars in the classpath, and of course do more testing before releasing the compiler. So far it is very encouraging.

It might also be worth looking into how many of those jars contain
indexes. Does running "jar i jarfilename.jar" on each jar change
performance? How much?

It's also worth looking at how many of them are sealed, and of those
that are not how many can be be sealed, so that javac doesn't have to
waste time scanning irrelevant classes in them. Assuming it's smart enough.

http://download.oracle.com/javase/6/docs/technotes/guides/extensions/spe...

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Dominik Dorn

Glassfish v3 is osgi based.
This means, that by default it only loads a bare bone
osgi system when started up and waits with loading subsequent stuff
( like
- the security manager for webapps,
- servlet stuff,
- jsp compiler,
- mojarra for jsf,
- weld + ejb scanning
- jersey for jax-rs
etc.
)
until the first request to a webapp requiring such a feature is made.

After that first request is made, all the modules required for that
feature are loaded and you will experience a much "faster" compilation.

Precompiling JSPs only helps partial as glassfish still has to load
the jsp handler/compiler _even if the JSPs are precompiled_.

But those things are only a issue (imo not a problem) in a
development environment and also only on first startup of the application
server. In a production environment you're probably are the first visitor after
a server restart just to check "if it worked", so again, its only affecting the
developer and not the regular user.

So how speeding up development of jsp applications in Glassfish v3?
==========================================

For JSF/JSP development I would recommend using "exploded" web-archives instead
of .war because you can then only update that specific JSP/JSF-View
instead of redeploying the whole application as it is made when
updating the war in the autodeploy folder.

If you're using the exploded version, I would also recommend using
dynamic reloading with the /.reload file which reloads your app quite
fast (depending on the size of the application)

I'm using maven and usually work with exploded archives and preventing
test-execution on deploying. My command line usually looks like this
(being skriptum the finalName in the pom's configuration)

# first time deployment
mvn clean compile package war:exploded -Dmaven.test.skip=true &&
asadmin deploy --contextpath / target/skriptum

# subsequent deployments
mvn clean compile package war:exploded -Dmaven.test.skip=true && touch
target/skriptum/.reload

After a few reloadings (20+, depending on application size) you will
run out of permgen space and have to kill glassfish. To get started
again, you'll have to
remove some stuff, as you would have problems on deployments after
server restart. For this I created an alias like this (you have to
replace your path to glassfish)

alias gf-clean='rm
/home/domdorn/tmp/glassfish/glassfishv3/glassfish/domains/domain1/generated/*
/home/domdorn/tmp/glassfish/glassfishv3/glassfish/domains/domain1/osgi-cache/*
/home/domdorn/tmp/glassfish/glassfishv3/glassfish/domains/domain1/logs/*
-R'

For updating JSF-Views/JSPs I simply tell IntelliJ Idea to use the
exploded folder
and press CTRL+F9 when I want to "deploy" the page again. This works
good for JSPs/JSFs xhtml, but if you have servlets/jsf beans you have
to use the command for subsequent deployments mentioned above.

I hope this helps.

Dominik

--
Dominik Dorn
http://dominikdorn.com
http://twitter.com/domdorn

Tausche Deine Lernunterlagen auf http://www.studyguru.eu !

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

kchung
Offline
Joined: 2004-05-06

I've done some experiment on the JSP compiler and got some interesting results.

Remember I mentioned that there are over 250 jars in the javac classpath? I looked at the list and noticed and most of them are not needed. I've modified the JSP compiler to only include about 8 jars (servlet and JSP apis, JSP implementation, JSTL and JSF jars etc) to javac, and rerun our recur2.jsp and bracket.tag test.

The numbers for the initial compilation are
G time for bracket.tag: 17
C time for bracket.tag: 703
G time for recur2.jsp: 908
C time for recur2.jsp: 87

The numbers for redeployment are 1, 104, 119, 76

There are big improvements over our original numbers, especially the C numbers:

Initial: 18, 1337, 1771, 171.
redeploy: 1, 159, 176, 161

They are also comparable to those in V2:

Initial: 15, 759, 895, 83, and
redeploy: 1, 86, 94, 75

I'll need figure a way to not to hardcode the specific jars in the classpath, and of course do more testing before releasing the compiler. So far it is very encouraging.

tmpsa
Offline
Joined: 2010-02-01

This looks promising.

So if I understand all this correctly, we've so far found two things that each contribute to the surprisingly slow startup of JSPs in v3:

1. The classpath for javac (after JSP compilation) contains lots (250) of unnecessary JARs.
2. The Security Manager is turned on by default in v3

When it comes to a [i]production[/i] installation, my guess is that the slow startup of JSPs is less of a problem, since there the JSPs are used over and over again, and the initial delay for compilation is only an annoyance once.

Message was edited by: tmpsa

kchung
Offline
Joined: 2004-05-06

> When it comes to a [i]production[/i] installation, my
> guess is that the slow startup of JSPs is less of a
> problem, since there the JSPs are used over and over
> again, and the initial delay for compilation is only
> an annoyance once.

Right. However, the compilation speed is more of an issue in application development, where slow turn around becomes a productivity issue.

Anyway, thanks for sticking with me in exploring this. I'd still appreciate your giving me a simplified test case for the JSP compiler. I may be able to use it to find other areas for improvements.

tmpsa
Offline
Joined: 2010-02-01

I'll be happy to provide a simplified test case; this issue is really important to me. But I don't know exactly what you need. And as far as I can tell, your simple test case (the one with a .JSP and .TAG file) reproduces the problem very well. Or...?

Cheers!
Per Lindberg

kchung
Offline
Joined: 2004-05-06

I was a little worried by your previous statement: "On v3 after redeployment it takes about 36 s to get the login page, and about 13 s to get the home page." I would like to have a reals test case for me to investigate the performance more. The apparent slowness of accessing the login page might well be attributed to osgi startups, like Dominik had suggested, and not just JSP compilations, but I need to be sure.

For now maybe I can go ahead and put in the fix for trimming javac classpaths, and we'll see if you get better timing in the responses.

tmpsa
Offline
Joined: 2010-02-01

> I was a little worried by your previous statement:
> "On v3 after redeployment it takes about 36 s to get
> the login page, and about 13 s to get the home page."
> I would like to have a reals test case for me to
> investigate the performance more. The apparent
> slowness of accessing the login page might well be
> attributed to osgi startups, like Dominik had
> suggested, and not just JSP compilations, but I
> need to be sure.

Well, the 36 s + 13 s have shrunk to 11 s + 7 s after I turned the SecurityManager OFF (which was off by default in v2 but on by default in v3).

I don't exactly understand the bit about osgi startups. Perhaps someone can give the "osgi for dummies" explanation?

If it's of any help, I re-started Glassfish, waited a little extra moment for it to "settle down", and made another GET of the home page (no redeploy). That took about 12 s on my development box (WinXP, GF3) and 2 s on my production box (Virtualized Linux, GF2). Now, the platforms aren't exactly identical, and ideally I would like to do the same measurement with GF2 on my dev box. But wouldn't you agree that GF3 appears to be significantly slower for this case? Perhaps some stuff isn't battle ready in GF3 after restart?

Now, of course I don't re-start Glassfish with every redeploy (in fact, as seldom as possible), so this is not a problem at all for the "normal" development cycle of edit-compile-redeploy-test.

> For now maybe I can go ahead and put in the fix for
> trimming javac classpaths, and we'll see if you get
> better timing in the responses.

Absolutely! That would be great!

And for another test case, maybe there's some demo app that comes with Glassfish that we both can redeploy and time?

Cheers!
Per Lindberg

tmpsa
Offline
Joined: 2010-02-01

I have now made the same measurement (with SecurityManager OFF), but with the request being a GET via the main servlet, which then forwards to foo.jsp. Here are the numbers:

G time foo.tag | 0
C time foo.tag | 953
G time foo.jsp | 1062
C time foo.jsp | 891

In other words, same as the simpler test.

andjarnic
Offline
Joined: 2007-01-08

Hey all,

I can understand and appreciate the issue behind it being slow.. but if it's fast after first access, why not have it pre-compile them all upon deploy (at least to production)?

Also, I am not sure if Eclipse can be set up this way, but I am pretty sure netbeans can just reload the jsp pages on the fly when you remotely connect the debugger... at least I think it can. I recall something like this in the past where I could save the .jsp page and it would reload when I accessed it without having to build/deploy the .war file each time. That said, I now do the build .war, redeploy to autodeploy folder myself. I still haven't figured out how to deploy without using the autodeploy folder short of using the admin interface to load the .war file. Is there some way to point a domain to one (or more) developer paths where are .war files are located.. or more so, our class files and web pages, so that it can quickly reload from our actual project path instead of having to redeploy each time we make a change?

kchung
Offline
Joined: 2004-05-06

> Hey all,
>
> I can understand and appreciate the issue behind it
> being slow.. but if it's fast after first access, why
> not have it pre-compile them all upon deploy (at
> least to production)?
>
Yeah, we also recommend pre-compiling JSP files at production. But in some cases, JSP files are generated dynamically and accessed almost immediately. In such a case, it might make more sense not to pre-compile the JSP files to avoid a big response delay.

> Also, I am not sure if Eclipse can be set up this
> way, but I am pretty sure netbeans can just reload
> the jsp pages on the fly when you remotely connect
> the debugger... at least I think it can. I recall
> something like this in the past where I could save
> the .jsp page and it would reload when I accessed it
> without having to build/deploy the .war file each
> time. That said, I now do the build .war, redeploy to
> autodeploy folder myself. I still haven't figured out
> how to deploy without using the autodeploy folder
> short of using the admin interface to load the .war
> file. Is there some way to point a domain to one (or
> more) developer paths where are .war files are
> located.. or more so, our class files and web pages,
> so that it can quickly reload from our actual project
> path instead of having to redeploy each time we make
> a change?

If you use asadmin cli command to deploy your application, you can do so from a directory, without having to create a war file first. Just do a

asadmin deploy path-to-your-dir

Once deployed, you can freely modify the JSP files in your directory, and they'll be compiled and loaded as needed. Doing it this way would also avoid long wait in the modify-deploy-run cycle, since only the modified JSP pages will be recompiled. If you do an asadmin deploy every time you change something, then potentially all JSP pages will need to be recompiled, because asadmin deploy wipes out all the generated files.

tmpsa
Offline
Joined: 2010-02-01

There is more than the one-line index.jsp. As I said, there's a login.jsp and a home.jsp. Each takes considerably longer to start/load/grok/compile/whatever in V3.

I changed org.apache.jasper.level=FINE in /domains/domain1/config/logging.properties
and behold, this time I got lots of entries in server.log! (I wonder why that didn't work when I used the admin console...?) A snip of my server.log after a redeploy and login is attached to this post.

From what I can understand, Jasper logs the following "Compiled" times in ms (in order of appearance):

6454 index.jsp
2813 label.tag
1860 row.tag
2641 text.tag
1844 textRow.tag
1891 password.tag
1844 passwordRow.tag
2563 submit.tag
1844 submitRow.tag
2282 login.jsp
2281 only.tag
2875 a.tag
2500 home.jsp

What strikes me is that the one-liner index.jsp takes such a long time.

Also, the tag files are really very simple "macros" to wrap a few single HTML tags. Should they really take so long to compile?

I also made a list of the "Generated ... total=" times:

125 index.jsp
156 label.tag
3078 row.tag
16 text.tag
7697 textRow.tag
15 password.tag
1953 passwordRow.tag
0 submit.tag
2640 submitRow.tag
18031 login.jsp
0 only.tag
110 a.tag
5437 home.jsp

I understand these times even less. I may be reading the server.log file wrong, so please check it. There's also a lot of other stuff in it that I don't understand so well...

Hope this will bring the issue forward!

Regards!
Per Lindberg

kchung
Offline
Joined: 2004-05-06

Thanks Per, for taking the time to get the numbers for me!

The "Generated" times are the times spent in compiling the JSP files to Java files, while the "Compiled" times are those spent in javac, comiling Java files to class files. There are a couple of things to remember when looking at the numbers.

1. The first "Compiled" time is always big, since it takes time to startup javac. Subsequent javac compilations should be much faster. Try redeploy your app again, and see the numbers go down.

2. The "Generated" time for a jsp file actually includes the time it takes (Generated and Compiled) to compile all the dependent tag files. That why the generated time for login.jsp and home.jsp is large, probably because they reference tag files which may in term reference other tag files.

I have done some measurements on the compilation times on v2 and v3. My test case is a simple jsp files that reference another simple tag files:

bra.jsp:

<%@ taglib prefix="test" tagdir="/WEB-INF/tags" %>

begin



qwertyui




end

brack.tag:
[== ==]

I got the following times:

| v2 initial | v2 redeploy | v3 initial | v3 redeploy |
G time brack.tag | 15 | 1 | 18 | 1 |
C time brack.tag | 759 | 86 | 1337 | 159 |
G time bra.jsp | 895 | 94 | 1771 | 176 |
C time bra.jsp | 83 | 75 | 171 | 161 |

Several things are obvious:

1. G time for bra.jsp is greater than G and C times for brack.tag because the times in brack.tag are included.

2. The times after redeploy are much less than the initial time.

3. V3 times are larger than V2 times, like you all said. But not as bad as I was led to believe. I can probably explain why javac take more time in V3: it has now more jar files in javac classpath. There are now over 250 of them!

I'll certainly look into this more, to see where why JSP compilation is slower in V3. It would great if you can give your test case. It doesn't have to run, just needs to able to compile. Thanks.

kchung
Offline
Joined: 2004-05-06

Repost with better formatting, hopefully.

Thanks Per, for taking the time to get the numbers for me!

The "Generated" times are the times spent in compiling the JSP files to Java files, while the "Compiled" times are those spent in javac, comiling Java files to class files. There are a couple of things to remember when looking at the numbers.

1. The first "Compiled" time is always big, since it takes time to startup javac. Subsequent javac compilations should be much faster. Try redeploy your app again, and see the numbers go down.

2. The "Generated" time for a jsp file actually includes the time it takes (Generated and Compiled) to compile all the dependent tag files. That why the generated time for login.jsp and home.jsp is large, probably because they reference tag files which may in term reference other tag files.

I have done some measurements on the compilation times on v2 and v3. My test case is a simple jsp files that reference another simple tag files:

bra.jsp:
<%@ taglib prefix="test" tagdir="/WEB-INF/tags" %>
begin


qwertyui


end

brack.tag
[== ==]

I got the following times:

| v2 initial | v2 redeploy | v3 initial | v3 redeploy |
G time brack.tag | 15 | 1 | 18 | 1 |
C time brack.tag | 759 | 86 | 1337 | 159 |
G time bra.jsp | 895 | 94 | 1771 | 176 |
C time bra.jsp | 83 | 75 | 171 | 161 |

Several things are obvious:

1. G time for bra.jsp is greater than G and C times for brack.tag because the times in brack.tag are included.
2. The times after redeploy are much less than the initial time.
3. V3 times are larger than V2 times, like you all said. But not as bad as I was led to believe. I can probably explain why javac take more time in V3: it has now more jar files in javac classpath. There are now over 250 of them!

I'll certainly look into this more, to see where why JSP compilation is slower in V3. It would great if you can give your test case. It doesn't have to run, just needs to able to compile. Thanks.

tmpsa
Offline
Joined: 2010-02-01

> The "Generated" times are the times spent in
> compiling the JSP files to Java files, while the
> "Compiled" times are those spent in javac, comiling
> Java files to class files. There are a couple of
> things to remember when looking at the numbers.
>
> 1. The first "Compiled" time is always big, since it
> takes time to startup javac. Subsequent javac
> compilations should be much faster. Try redeploy your
> app again, and see the numbers go down.
>
> 2. The "Generated" time for a jsp file actually
> includes the time it takes (Generated and Compiled)
> to compile all the dependent tag files. That why the
> generated time for login.jsp and home.jsp is large,
> probably because they reference tag files which may
> in term reference other tag files.

Ok, thanks for the explanation!

> I have done some measurements on the compilation
> times on v2 and v3. My test case is a simple jsp
> files that reference another simple tag files:
>
> bra.jsp:
> <%@ taglib prefix="test" tagdir="/WEB-INF/tags" %>
> begin
>
>
> qwertyui
>

>

> d
>
> brack.tag
> [== ==]
>
> I got the following times:
>
> | v2 initial | v2
> redeploy | v3 initial | v3 redeploy |
> G time brack.tag | 15 |
> 1 | 18 |
> 1 |
> 759 | 86 | 1337 |
> 159 |
> | 895 | 94 | 1771
> | 176 |
> C time bra.jsp | 83 |
> 75 | 171 | 161
> |
>
> Several things are obvious:
>
> 1. G time for bra.jsp is greater than G and C times
> for brack.tag because the times in brack.tag are
> included.

Right.

> 2. The times after redeploy are much less than the
> initial time.

I don't understand this, and don't know how to reproduce it. Redeploy?? For me, that's building a new WAR file and copying it to .../domain1/autodeploy. And then I get the same (long) times for Generated and Compiled. (At least it's reproducible... :-) )

> 3. V3 times are larger than V2 times, like you all
> said. But not as bad as I was led to believe. I can
> probably explain why javac take more time in V3: it
> has now more jar files in javac classpath. There are
> now over 250 of them!

Could be a clue, yes. I wouldn't be surprised if there are several factors, all adding to the extra time.

> I'll certainly look into this more, to see where why
> JSP compilation is slower in V3. It would great if
> you can give your test case. It doesn't have to run,
> just needs to able to compile. Thanks.

I'll try to make a small test case, more similar to what my application is doing. Btw, I use PRG, so all requests first go to my main controller servlet (and massaged using EJBs) and then later redirected to a resulting Wiew JSP.

Meanwhile, I took your test case, renamed it to foo.jsp and foo.tag, and ran it in my app. First I logged in and got to the main.jsp, then entered foo.jsp directly in the URL (so no PRG there). Results below. I do all measurements twice, to see any spurious variations. I don't understand how to do the 'redeploy' test case, please explain.

Today, I also stumbled on another problem; exec("bar.exe") from a servlet causes a security exception. It turns out that v2 has the Security Manager off by default, and v3 has it on by default. Sneaky! So I turned the Security Manager off using the Admin Console, and suddenly my measurements produced different, lower, numbers. So that could be yet another factor!

v3 initial | v3 initial with Security Manager

G time foo.tag | 0 0 | 0 0
C time foo.tag | 953 987 | 1766 1735

G time foo.jsp | 984 1016 | 1828 1812
C time foo.jsp | 891 937 | 1719 1641

One thing that's immediately notable is that our times for "v3 initial" C time foo.jsp is widely different.

What do you think?

kchung
Offline
Joined: 2004-05-06

By redeploy, I meant a undeploy, followed by a deploy. It is just a way to force another round of compilations. I think the reason javac takes less time after redeployment, is because in V3, javac is invoked programmatically, and once loaded, it stays loaded. Hence the class loading time is minimized after the initial compilation. Also I suspect it also caches the jar files it needs for compilation.

Turning on the security manager would definitely slow down the compilation. I didn't realize that V2 have it off by default! I'll investigate this more. Maybe I should also turn off validation in xml parsing.

tmpsa
Offline
Joined: 2010-02-01

> By redeploy, I meant a undeploy, followed by a deploy.

I don't get it. Isn't that exactly what happens when I copy a new version of my EAR file to the autodeploy directory? When I do, [i]each[/i] JSP has a sloow startup (and is quick on a second request).

> It is just a way to force another round of
> compilations. I think the reason javac takes less
> time after redeployment, is because in V3, javac is
> invoked programmatically, and once loaded, it stays
> loaded. Hence the class loading time is minimized
> after the initial compilation. Also I suspect it
> also caches the jar files it needs for compilation.

If I understand this correctly, then only the [i]very first[/i] compilation would be slow, and [i]only[/i] after a restart of Glassfish. In other words. compiling another JSP should be faster than compiling the first JSP. I don't think I have seen that phenomenon. Or am I missing something?

> Maybe I should also turn off validation in xml parsing.

Well... my IntelliJ IDEA checks the JSP code on the fly, so if that's a big time-gobbler then perhaps I don't need another check... On the other hand, I guess we will get more informative error messages with xml parsing on, if there's a problem with a JSP? If so, that would save a lot of trouble and head-scratching, right?

kchung
Offline
Joined: 2004-05-06

> I don't get it. Isn't that exactly what happens when
> I copy a new version of my EAR file to the autodeploy
> directory? When I do, [i]each[/i] JSP has a sloow
> startup (and is quick on a second request).
>
Yea, guess that is the same as an undeploy and deploy. I am used to do everything with asadmin. :-)

>
> If I understand this correctly, then only the [i]very
> first[/i] compilation would be slow, and [i]only[/i]
> after a restart of Glassfish. In other words.
> compiling another JSP should be faster than compiling
> the first JSP. I don't think I have seen that
> phenomenon. Or am I missing something?
>
But have you looked at the numbers? In particular, the C numbers on the first compilation is painfully slow, but is subsequent compilations are much faster. I thought that was your complain.

> > Maybe I should also turn off validation in xml
> parsing.
>
> Well... my IntelliJ IDEA checks the JSP code on the
> fly, so if that's a big time-gobbler then perhaps I
> don't need another check... On the other hand, I
> guess we will get more informative error messages
> with xml parsing on, if there's a problem with a JSP?
> If so, that would save a lot of trouble and
> head-scratching, right?

The JSP page will be validated only if it is in xml syntax. For standard syntax, xml validation applies only to parsing the tld and web,xml files.

I thought validation is on by default in V3. I just discovered it is actually off by default. Our intention has been to make it on by default, but now I afraid if I do that, the compilation would be even slower!

tmpsa
Offline
Joined: 2010-02-01

> > If I understand this correctly, then only the
> > [i]very first[/i] compilation would be slow, and
> > [i]only[/i] after a restart of Glassfish. In other words.
> > compiling another JSP should be faster than
> > compiling the first JSP. I don't think I have seen that
> > phenomenon. Or am I missing something?
> >
> But have you looked at the numbers? In particular,
> the C numbers on the first compilation is painfully
> slow, but is subsequent compilations are much faster.
> I thought that was your complaint.

My complaint was and is that [i]all[/i] JSP compilations is significantly slower in v3. Of course, the six seconds for the very first compilation (index.jsp) is even worse. But the two seconds for each subsequent compilation is [i]also[/i] annoying.

kchung
Offline
Joined: 2004-05-06

It got my attention too! :-)

Not that I don't believe you, but it's hard to imagine that JSP compilation of a one line JSP file can cause such a big change in redeployment time. Wish we know what percentage of the deployment time was spent in JSP compilation. What do you get when you deploy your app with precompilejsp set to false?

When you set the logging level to FINE (I did that by editing the file /domains/domain1/config/logging.properties to include the line org.apache.jasper.level=FINE), you should get the compilation time in server.log:

[#|2010-09-02T13:20:11.147-0700|FINE|glassfish3.1|org.apache.jasper.compiler.Compiler|_ThreadID=16;_ThreadName=Thread-1;ClassName=org.apache.jasper.compiler.Compiler;MethodName=generateJava;|Generated /export/work/v3x/glassfishv3/glassfish/domains/domain1/generated/jsp/Test/org/apache/jsp/test_jsp.java total=111 generate=20 validate=88|#]

[#|2010-09-02T13:20:16.170-0700|FINE|glassfish3.1|org.apache.jasper.compiler.Compiler|_ThreadID=16;_ThreadName=Thread-1;ClassName=org.apache.jasper.compiler.Compiler;MethodName=generateClass;|Compiled /export/work/v3x/glassfishv3/glassfish/domains/domain1/generated/jsp/Test/org/apache/jsp/test_jsp.java 5017ms|#]

The first number is for compiling .jsp to .java, and the second for compiling .java to .class. In this case, javac takes the majority of the time (5017ms vs. 111 ms).

hzhang_jn
Offline
Joined: 2005-07-22

kin-man, I think the jsp compilation is done in this method in WebDeployer:

@Override
protected void generateArtifacts(DeploymentContext dc)
throws DeploymentException {
DeployCommandParameters params = dc.getCommandParameters(DeployCommandParameters.class);
if (params.precompilejsp) {
//call JSPCompiler...
runJSPC(dc);
}
}

So if you add some code to log the starting and ending time around the "runJSPC" call, the user should be able to find out how much time the JSP compliation is taking by setting appropriated log level.

tmpsa
Offline
Joined: 2010-02-01

I have the same sad experience, too. After upgrading from Glassfish 2 to 3, my JSPs are [i]terribly[/i] slow - at the first request. (After that, they are quick). Could it really be a slow new JSP compiler?

What is the General Wisdom on this issue? I have a hunch that we're not the only ones.

kchung
Offline
Joined: 2004-05-06

The JSP compilers in V2 and V3 are virtually identical, so the apparent slowness of JSP compilation in V3 is probably due to other factors, such as changes in classloading, or the additions of new jars etc. I'll need to do some measurements and investigations to get some insights into this issue.

But first, can you quantify "slowness" in V3 JSP compilations speed? Is is as bad as 100% slower than in v2? Also, when you say slow at the first request, and quick after, do you mean that only the first request after you start the server is slow, but other requests, even to different pages, are quick?

Thanks for reporting this, it is the first complains of this kind that we've got for v3.

tmpsa
Offline
Joined: 2010-02-01

You may well be right, kchung. It may not be the JSP compilation [i]itself[/i] that has become slower, but some other related mechanism. But who knows?

What I see is after a redeploy is that it takes a loong time to get to my first login JSP page (I use form-based authentication with redirect to https). After login, it takes a loong time to get the home page. Then it's the same story for each new different page.

But once a page has been visited, it's quick. That's why my prime suspect was JSP compilation.

I run my development on an AMD Phenom 9650 Quad-Core 2.3 GHz with 3 GB RAM running WinXP. I have also increased the memory for JVM to 1000m as recommended by J-F Arcand. (Not that it seems to help).

Some numbers:

On v2 after redeployment it took about 5-10 s to get the login page. There were no further delays after that, and getting the home page etc was very quick (< 1 s).

On v3 after redeployment it takes about 36 s to get the login page, and about 13 s to get the home page. Getting another page takes 7 s. The CPU usage is high during this time. After that, getting these two pages again is very quick, as with v2.

(The 5-10 s and 36 s to get the login page includes the time before my webapp even answers).

This of course slows down my edit-deploy-test cycle considerable. Quite frustrating.

Thanks for looking ito this!

Cheers,
Per Lindberg

kchung
Offline
Joined: 2004-05-06

Wow, that's really slow! By a factor of 7!

Do you know how many pages are compiled in getting to your login page? What is the average size for those pages? If there are not too big, and you can shared them, can I use them for my test case?

Also, do you use specific JSP compilation options?

If you cannot share your files, one way to get the actual time for JSP comilations is to set the logging level for the module org.apache.jasper to FINE. This way you can compare the actual time for JSP compilation in v2, and v3.

If you really want to speed up your edit-deploy-test cycle, don't redeploy your app, Instead you can make you changes to the JSP pages directly in the deployed directory. This way, only the modified pages will be recompiled. The JSP engine can detected files that have been modified since the last compilation.

Thanks.

tmpsa
Offline
Joined: 2010-02-01

Yeah, this really got my attention. :-)

To get to the login page, the following things happen:

1. index.jsp is a one-liner that just redirects to my main servlet with a 'login' command (which does nothing except redirect to the home page). The servlet URL is protected with a in my DD.

2. The main servlet is 1400 lines of Java code, with injection of 14 EJBs. (Not that any of those are used in login). (I just added 1 to the DD, but that did not help, btw). It also has a ServletContextListener that sets up some Timers by calling EJB methods.

3. The home page is just a navigation menu.

As I said, this was really quick i v2.

I just noted in server.log that in V3 redeployment alone takes 9 s:

[#|2010-09-01T10:26:29.125+0200|INFO|glassfish3.0.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=28;_ThreadName=Thread-1;|fpcontrolserver was successfully deployed in 9 204 milliseconds.|#]

The EAR file is 1.4 MB.

I have not twiddled any JSP compilation options; I run GF 3 out of the box.

I changed the logging level for the module org.apache.jasper to FINE using the admin console. But I can't figure out where the output is... it's not in server.log.

At an early stage of the project I considered editing the JSP pages directly in the deployed directory, but decided against it. It would add some complication that I'm not comfortable with. So I don't think that's an option for me right now. I'm more interested in why suddenly everything became soo much slower with V3. Am I doing something wrong, or is this just the way V3 is?

Regards!
Per Lindberg

Paul Sandoz

Agreed, i have noticed this too. It takes 10 seconds or so to compile
a simple index.jsp.

Paul.

On Sep 1, 2010, at 11:05 AM, glassfish@javadesktop.org wrote:

> Yeah, this really got my attention. :-)
>
> To get to the login page, the following things happen:
>
> 1. index.jsp is a one-liner that just redirects to my main servlet
> with a 'login' command (which does nothing except redirect to the
> home page). The servlet URL is protected with a > constraint> in my DD.
>
> 2. The main servlet is 1400 lines of Java code, with injection of 14
> EJBs. (Not that any of those are used in login). (I just added > on-startup>1 to the DD, but that did not help,
> btw). It also has a ServletContextListener that sets up some Timers
> by calling EJB methods.
>
> 3. The home page is just a navigation menu.
>
> As I said, this was really quick i v2.
>
> I just noted in server.log that in V3 redeployment alone takes 9 s:
>
> [#|2010-09-01T10:26:29.125+0200|INFO|glassfish3.0.1|
> javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|
> _ThreadID=28;_ThreadName=Thread-1;|fpcontrolserver was successfully
> deployed in 9 204 milliseconds.|#]
>
> The EAR file is 1.4 MB.
>
> I have not twiddled any JSP compilation options; I run GF 3 out of
> the box.
>
> I changed the logging level for the module org.apache.jasper to FINE
> using the admin console. But I can't figure out where the output
> is... it's not in server.log.
>
> At an early stage of the project I considered editing the JSP pages
> directly in the deployed directory, but decided against it. It would
> add some complication that I'm not comfortable with. So I don't
> think that's an option for me right now. I'm more interested in why
> suddenly everything became soo much slower with V3. Am I doing
> something wrong, or is this just the way V3 is?
>
> Regards!
> Per Lindberg
> [Message sent by forum member 'tmpsa']
>
> http://forums.java.net/jive/thread.jspa?messageID=481553
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

kchung
Offline
Joined: 2004-05-06

> Agreed, i have noticed this too. It takes 10 seconds
> or so to compile
> a simple index.jsp.
>
> Paul.
>
Paul,

Can you give me more details about this? What your is system and platform? JDK version? Is the time for deployment with precompilejsp=true or compile with browser access? How simple is your simple index.jsp?

I it not my experience that V3 jsp compilation is much slower than V2. But since everybody (or almost everybody :-) ) is saying so, so there must be something that I've missed. And nobody is giving me specifics or a test case!

Thanks.

Paul Sandoz

On Sep 4, 2010, at 3:30 AM, glassfish@javadesktop.org wrote:

>> Agreed, i have noticed this too. It takes 10 seconds
>> or so to compile
>> a simple index.jsp.
>>
>> Paul.
>>
> Paul,
>
> Can you give me more details about this? What your is system and
> platform? JDK version?

It was a vanilla Web app created by the NBs 6.9 wizard deployed to GF
3.1 b19-09_03_2010 on the Mac.

> Is the time for deployment with precompilejsp=true or compile with
> browser access? How simple is your simple index.jsp?
>

The approximate time was from when i first accessed the index.jsp,
reloading is subsequently faster. I did not pre-compile the JSPs, i
just used what the defaults are as supplied by NBs.

> I it not my experience that V3 jsp compilation is much slower than
> V2. But since everybody (or almost everybody :-) ) is saying so, so
> there must be something that I've missed. And nobody is giving me
> specifics or a test case!
>

I dunno if it is slower than V2 or not. It's just from a user
perspective it is slow and much slower than Tomcat, which is ~ < 2s
for first deploy.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net