Comparing application server startup times?
A few months ago I read a blog post that compared different (Java) application servers with a particular focus on the time taken to start / restart the servers after deploying a new / changed piece of code, as well as a discussion on lost developer productivity across all those restarts.
I forgot to bookmark my blog; I have tried googling but I cannot find the original article.
Has anyone else seen / read this article or had links to related articles / statistics?
source to share
I think you are looking for Poll results: Java EE containers - heaven or hell? From JavaRebel strike> JRebel guys.
source to share
There are several articles about this, so it's hard for you to know which one you belong to.
That being said, it really depends on the tech stack. If you want a complete J2EE implementation, not just a J2EE container, then the startup time will be very different.
For example, Tomcat can be up and running in seconds. On my machine in about 1-2 seconds. It is of course a J2EE container. It does not include features like EJB. But these days, who really needs it.
Full J2EE implementations like JBoss and Weblogic, for example, will take much longer server startup time. Usually in half a minute to several minutes.
Again, you really need to figure out exactly what part of the J2EE stack you want, and if you're not going to fully use it, Tomcat is great for fast startups.
Also, even if you use Tomcat for development, that doesn't mean you need to use it for production. This does not mean that this is not a good production server, but simply a lighter one.
source to share
Let's start with the idea that the application should be deployed in full form just for integration testing. This happens twice a day. At other times you are doing unit testing and local integration (i.e. JUnit test with actual database connection) and those tests have zero run time.
My dev activity is this:
- write (mock) unit tests and code at the same time; maybe 20 times before the code works as I expect.
- record local integrated tests for main cases; run tests maybe 3 or 5 times before I'm sure it's ok
- package the entire app and walk through the script through the UI once or twice
When scheduling time, for example, AS startup time doesn't take much of my work.
So instead of complaining about AS, it's best to put effort into organizing the development process first.
source to share