To try it out, I did a few quick tests. For the record, what I tested was GlassFish v2.1.1, v3.1 Full, v3.1 Web Profile, and I included Tomcat 7 for one test just to compare. I also did this all on OS X on a fairly new MacBook Pro.
First, I deployed a fairly small and simple Web-app and then stopped and restarted each app-server several times. My observations on startup times and footprint after start were:
| Container | Startup Time | Footprint |
|---|---|---|
| GlassFish v2.1.1 | 16 sec | 178 MB |
| GlassFish v3.1 | 6.5 sec | 153 MB |
| GlassFish v3.1 Web Profile | 5 sec | 123 MB |
| Tomcat 7 | 1 sec | 74 MB |
This shows that v3 has clearly made improvements over v2 in both startup time and footprint This is as expected.
What surprised me a bit was that Web Profile had further improvements over the full profile, this because I thought only what was required would be started with the full profile and so it should basically match Web Profile in this case and it didn't. It was also significantly heavier weight. Does this make sense?
Also, Tomcat is clearly the speed demon and lightest weight, but this isn't really an apples to apples comparison as Tomcat doesn't offer as much as any of the other options. It still sets the standard for fast startup and small footprint though.
Next, I deployed another EAR and WAR file that make up our application. Here is what I observed:
| Container | Startup Time | Footprint |
|---|---|---|
| GlassFish v2.1.1 | 20 sec | 207 MB |
| GlassFish v3.1 | 24 sec | 400 MB |
Now this was more surprising. Not only did v3 take longer to startup, the footprint was nearly twice that of v2! Effectively, v2 added 4 seconds to startup a second WAR and an EAR, but v3 added nearly 18 seconds to do the same. And why v3 is using so much more memory, I'm not sure.
Now, perhaps my test is too simple or I'm not looking at the exact right metrics to really measure startup time. But what I'm using is the Real Memory reported by Activity Monitor and both the time it takes for "asadmin start-domain" to return the the start time reported in the server.log file.
As additional background, I'm deploying the same WAR and EAR files to both v2 and v3, and since they run in v2 they are not specific to EE 6 and the only EJBs are SSBs.
So GlassFish experts, help me out. Is what I'm seeing real? Is v3 really slower and larger than v2 for this type of use case?
Regarding the differences between the web and full profiles, even though the full profile doesn't fully load all unused modules, there is some overhead because the modules are there. The OSGi cache contains information about each module (or bundle in Felix logo). The web profile has 207 bundles, while the full profile has 251. The meta data for all of the modules has to be loaded even if they are not used. This is optimized, but it doesn't take zero time. This may not account for the full 1.5 sec., but it is part of it.
ReplyDeleteDoes your testing strategy include accessing a URL from the application for the first time? When the GlassFish team measures server startup time, we include an access to the application to make sure that everything that is needed for the application has been loaded.
Tom, thanks for the comment.
ReplyDeleteYeah, the 1.5 seconds delta between full and Web profile, I can understand. It was the big change the other way that was a surprise.
No, I didn't include accessing the URL for the first time in my test but I can try adding that. But since one of the apps is an EAR, how do you ensure it has been fully loaded? In v3 the log shows individual load times for each app, so what is included in that load time?
Tom, I did as you suggested and after startup accessed a URL in both Web apps, one which brings up a login page and another that actually queries the app deployed as an EAR, so once they both complete everything should be fully "up".
ReplyDeleteThis basically added about 5.5-6 seconds to both v2 and v3. So v2 is now 26 seconds and v3 is 30. So the extra time appears to be all during the server startup and initial deployment, not during the initial use of the app or any requisite completion of loading.
@Kevin I timed the startup of tomcat, GlassFish Server 3.1, and GlassFish 2.1.1 (including first access to port 8080). Not a scientific run on my ancient Macbook Pro, but:
ReplyDeleteTomcat: 4 seconds
GlassFish v2.1.1: 22 seconds
GlassFish Server 3.1: 7 seconds
Our startup results are similar, you just have a faster laptop :-)
Tomcat does not start in a second on my system, so it must start one or more daemon threads to initialize in the background, and returns control to the foreground - which exits the startup shell immediately. For GlassFish, append an "&" to the CLI to achieve the same results :-)
As for the rest of the testing, not sure how much time I have. I'm traveling next week so I have a lot of loose ends to address today.
Try posting to the GlassFish forums.
Thanks John. And yes, I know the standard Tomcat script runs in the background so I manually ran the catalina.sh script in the foreground for my testing.
ReplyDeleteI'll ask in the forums. Thanks!
Hi Kevin
ReplyDeleteCan you please try GlassFish 3.1.1_b11
http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/glassfish-3.1.1-web-b11.zip
http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/glassfish-3.1.1-b11.zip
regards
Richard
Nice blog post. I was looking out for ways to effectively measure web application deployment time on glassfish but couldn't much. I couldn't find any log statements in server.log of glassfish(v3.1.1) which could state that the deployment started or done. Can you share details on how did you measure the start up time?
ReplyDelete