Jay Fields is a software developer at DRW Trading. He has a passion for discovering and maturing innovative solutions. His most recent work has been in the Domain Specific Language space where he's delivered applications that empowered subject matter experts to write the business rules of the applications. He is also very interested in maturing software design through software testing. Jay is a DZone MVB and is not an employee of DZone and has posted 115 posts at DZone. You can read more from them at their website. View Full User Profile

Undervalued Start and Restart Related Questions

  • submit to reddit

How long does it take to start or restart your application?

Start-up time tends to be a concern that's often overlooked by programmers who write unit tests. It will (likely) always be faster to run a few unit tests than start an application; however, having unit tests shouldn't take the place of actually firing up the application and spot checking with a bit of clicking around. Both efforts are good; however, I believe the combination of both efforts is a case where the sum is greater than the parts.

My current team made start-up time a priority. Currently we are able to launch our entire stack (currently 6 processes) and start using the software within 10 seconds. Ten seconds is fast, but I have been annoyed with it at times. I'll probably try to cut it down to 5 seconds at some point in the near future, depending on the level of effort needed to achieve a sub-5-second start-up.

That effort is really the largest blocker for most teams. The problem is, often it's not clear what's causing start up to take so long. Performance tuning start-up isn't exactly sexy work. However, if you start your app often, the investment can quickly pay dividends. For my team, we found the largest wins by caching remote data on our local boxes and deferring creating complex models while running on development machines. Those two simple tweaks turn a 1.5 minute start-up time into 10 seconds.

If your long start-up isn't bothering you because you don't do it very often, I'll have to re-emphasize that you are probably missing out on some valuable feedback.

Not time related, but start related: Does your application encounter data-loss if it's restarted?

In the past I've worked on teams where frequent daily roll-outs were common. There are two types of these teams I've encountered. Some teams do several same day roll-outs to get new features into production as fast as possible. Other teams end up doing multiple intraday rollouts to fix newly found bugs in production. Regardless of the driving force, I've found that those teams can stop and start their servers quickly and without any information loss.

My current team has software stable enough that we almost never roll out intraday due to a bug. We also have uptime demands that mean new features are almost never more valuable than not stopping the software intraday. I can only remember doing 2 intraday restarts across 30 processes since February.

There's nothing wrong with our situation; however, we don't optimize for intraday restarts. As part of not prioritizing intraday restart related tasks, we've never addressed a bit of data-loss that occurs on a restart. It's traditionally been believed that the data wasn't very important (nice-to-have, if you will). However, the other day I wanted to rollout a new feature in the morning - before our "day" began. One of our customers stopped me from rolling out the software because he didn't want to lose the (previously believed nice-to-have) overnight data.

That was the moment that drove home the fact that even in our circumstances we needed to be able to roll out new software as seamlessly as possible. Even if mid-day rollouts are rare, any problems that a mid-day rollout creates will make it less likely that you can do a mid-day rollout when that rare moment occurs.

Tests and daily rollouts are nice, but if your team is looking to move from good to great I would recommend a non-zero amount of actual application usage from the user's point of view and fixing any issues that are road-blocks to multiple intraday rollouts.

From http://blog.jayfields.com/2011/07/undervalued-start-and-restart-related.html

Published at DZone with permission of Jay Fields, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Zqudlyba Navis replied on Thu, 2011/07/14 - 1:51am

Wow. 10 seconds. It's probably not on WebSphere stack.

How large is the project? e.g. lines of code, number of full time equivalent developers, budget, number of EARs or WARs, etc.

Is it a stand alone java app (e.g. ui-service-persistence), or does it connect to many systems (eg. mainframes, web services, file systems, MQ, esb, high frequency trading, etc.

Alexander Smirnov replied on Thu, 2011/07/14 - 11:18am

We are going in different direction. Instead of decrease startup time of whole application, we do that for UI part only. So, the project structure contains these modules: - domain model objects ( JPA entities ). - Business logic interfaces. - EJB implementation for business logic, that uses real database storage, web services and so on. - Stub implementation for the same interfaces, without any connections to real world ( plain Java ). - test project for the business layer. We run these tests for both real implementation and stubs to ensure that they are identical. - web UI. It packaged with real implementation for production, and with stubs for UI development ( we use Maven profiles to switch dependencies ). Therefore, in the UI development mode, startup time is close to zero, and developers can use hot deployment in IDE. It takes additional time to create stubs for any business interface, but fast deployment cycle for UI development worth it.

Comment viewing options

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