When developing an application in a web server environment, the ease of use and startup time of the application are crucial elements for best performance. Due to this, the Hot Code Replace (HCR) debugging technique was developed to “facilitate experimental development and to foster iterative trial-and-error coding,” effectively improving application development performance. In brief, HCR allows you to “start a debugging session on a given runtime workbench and change a Java file in your development workbench, and the debugger will replace the code in the receiving VM while it is running.” In essence, no restart is needed.
However, when changing either class signatures or instance variables, HCR will not work; a restart is required for changes to take effect. “Context Reloading”, necessary for changes in configuration or property files to take effect, also requires a restart.
This is where problems arise. The need to restart the application consumes too much time. In my experience, one of my projects takes an average of three (3) minutes to restart. Restarting ten (10) times already uses up 30 minutes of valuable development time.
My current development environment: Mac OS X 10.4.11, Maven 2, Struts 1, Spring 2.0, Hibernate 3, Eclipse Galileo
The following measures below were taken to improve performance. This can serve as guidelines for the enhancement of server startup time.
1. Disable Xdoclet Maven Plugin (for hbm generation) when not needed. This decreased startup time from 2:59 to 2:32.
2. Lazily instantiate beans during development. A major bottleneck in application startup occurs during Spring pre-instantiation of singletons (our project has 677 beans defined in application context) in factory. Set Spring’s “default-lazy-init” to “true”. Startup time decreased from 2:32 to 1:58.
3. Upgrade project execution environment to the latest version of JVM. I upgraded the default Mac OS X default JVM 1.5 to SoyLatte JDK 6, further decreasing startup time from 1:58 to 1:02.
4. Use embedded Jetty instead of Maven Jetty Plug-in or Eclipse Jetty Adapter Plug-in when starting the web server. This lessened startup time even further, from 1:02 to 0:37.
The measures described above effectively shortened the average startup time from 2:59 to 0:37!
So if you want to boost your productivity, try out the guides set above! These tips will definitely make startup time faster and help improve your application development performance.
5 thoughts on “Improve Java Web Development Server Startup Time”
Good tips, I’ll be looking into some of them (I’ve been working on one crappy application that had a 9 minute build / deploy / startup time which I’ve so far been able to reduce to 3:30). The whole notion of needing to rebuild / redeploy / restart in the Java world was a shock to me coming from ASP.NET, which has a special compilation model and other features which let you change code -> save -> refresh browser all day long. Grails 1.2 is very good too for the Java world.
Hi Stephen,
Welcome to the Java world! You may also want to take a look at JRebel which eliminates some of the need to redeploy and restart your application. It costs some money but it may help to boost your productivity. Yes, Grails as well as other frameworks are excellent and very productive. You’ll find quite a lot of these in the Java community.
Thanks for the warm welcome, Jacobb. I’ve actually tried out JRebel and it really does do a pretty good job, definitely worth the under $100 price for those who treasure their sanity. I’ll tell you, one really good shock coming from ASP.NET was discovering MVC, which at first seemed hideous and tedious with XML wiring and JSP view shortcomings, but paired with a dynamic / convention-over-configuration framework like Grails it really shines and is so clearly superior to the ASP.NET Page paradigm.