It’s well know that Netbeans supports Glassfish very well. One of the features I like most is incremental deployment, because it can save you a lot of time during development. Adam Bien posted some performance figures. Even for a large project it takes just 6 seconds using Netbeans’ incremental redeployment.
Compared to Netbeans, Eclipse with WTP seems to offer only 2nd class support for Glassfish. Unfortunately, this did not change with Eclipse 3.4 and WTP 3.0. For example, directory deployment is not supported. Publishing a EAR project to Glassfish always implies creating a new EAR File. I played around with it a bit and decided to switch back to ant. It requires just a simple ant script to copy the files into a directory structure and to call
asadmin deploydir. This reduced deployment time by 20% for my EAR project. Another advantage of exploded directory deployment is that changes in JSPs (including JSF) do not require redeployment. Changes are immediately visible after copying the JSP files.
The next observation was that antivirus software had a major impact on deployment performance. I do not recommend to switch it off completely, but I was curious to get a number, which turned out to be surprisingly high: Without virus protection, deployment got over 60% faster! Maybe I should consider replacing Kaspersky with a faster virus scanner… At least, Kaspersky allows to exclude file checking for programs, which are considered trustworthy. By excluding only the java.exe used by Glassfish, deployment got around 15% faster after all. In my opinion, this is a OK compromise of performance and protection. But, as said before, I do not want to recommend how you use your virus protection: it is totally up to you.
Let’s have closer look at the graphs and the set-up. I tested it with a small EAR project consisting of two EJB jars and one web application WAR. A few entity beans are used with drop-and-create-tables, so deployment includes some database operations. The first graph shows redeployment time in seconds, which were measured three times. The initial deployment was not measured to get consistent and repeatable values. Anyway, the values are just a snapshot for a random project and are most probably not representative. I think performance will depend highly on your project and virus scanner, but the presented figures should give you at least a clue.
The second graph visualizes the same values, but shows the performance gain in percent. The combination of directory deployment and excluding java.exe from virus file scanning resulted in a 40% improvement.
Of course, deployment time is just one factor and in an efficient development process, frequent deployment is often avoided. Usually, this is done using a unit test based development approach. Another very interesting alternative is JavaRebel, which I will try to cover in another article soon.