Is web application startup time really that important?

Question

Had a conversation with someone about adding some initialization code on application startup and he complained about that causing an increasing in the startup time. He couldn't really state a reason (gut feeling or something, don't know). This is not a heavy use application and starts in about a minute or so, we deploy a few times a year.

I remember reading such advice on questions on SO some time ago, people advising to initialize on startup instead on access of page with the "if you can afford the penalty" stamp on.

I've worked with web apps that started from 30 seconds to 4-5 minutes but once online they rocked.

So what am I missing? Unless it's a vital application like... I don't know... for the financial market, medical applications, space exploration etc, is it really that important the startup time?

P.S. I'm strictly referring to web apps, desktop apps are bound to start lightning fast.

Answer 1

It can be a big factor during development: if your platform does not support changing code in a running application, then the startup time becomes part of your feedback cycle, and there, even 30 seconds are painful and a threat to productivity.

For the production environment, it really does not matter; either a little downtime is acceptable and 5 minutes are still not much, or it's not and you have to implement some sort of live switchover.

Answer 2

I believe this is the case when Hegel's famous dialectical principle of transition from quantity to quality actually works.

You see, timing always is important. I agree with Michael Borgwardt's words about importance of quick build during development/testing, but I insist that (may be in some other way) it is also very important for production.

Each developer who deployed some bad code to production knows that hotfix provided in 5 minutes and in 1 minute are really, really different things.

Answer 3

The real questions is whether the app will work without the initialization. We have new hires who obsess about "performance", my stock answer is I don't care how quickly you give the wrong results. IMHO cutting corners, mangling algorithms because "it will be faster this way", and other great ideas only introduce bugs.

If the initialization is required then do it. How much time will be wasted when the end users get the wrong results, eventually figure out the web app is wrong, call you and complain, and you have to go back and debug/fix/test/redeploy? now ask your colleague how time has been saved. (and I'd bet your server cores are 99% idle anyway)

Answer 4

This question doesn't ask about any particular platform. There are platforms on which startup time really is very important.

For instance, on Google App Engine; if your page isn't getting accessed (or rather, is getting accessed less frequently than another application on the same node), it will be unloaded occasionally.

Thus, if you're in the bottom 99% of site access frequency, then startup time is access time; your application is being restarted at nearly every access. if you are in the top 1%, then your application is getting started up on many nodes, and although many page accesses will return from an already started instance, some still won't, and so you'll have intermittent, long access times.

This same thing is true on many other hosting environments. Leaks in third-party libraries, or even in your own code that have simply eluded discovery, might mean that the only reliable way to run your web service is to have it reload every so many requests (often between 100 to 10,000), and so the start up time is paid frequently. Using this pattern is acceptable when an app is leaky, but starts up quickly; it's unworkable when the app takes more than a few seconds to start.

Answer 5

You're running the risk of your application being considered sub-standard or worse yet, your development ability. Now, this app may be saving someone so much time and/or do such a needed task that the thankful users can look past the long startup.

It may take longer to program in such a way to lazily load the app, but only the stakeholders can determine if it is worth it. I had a report that ran in 55 sec. and we got it down to 35. No one noticed. Although I spent twice as much time getting it from 35 to 18, everyone noticed and were thankful and impressed. Going from 5 to 3 minutes for an app used a few times a year is not big deal. Users will just have less time to spend on Facebook or getting coffee.

Perception is the key. If the compay is not happy with the development teams in general and this app specifically, you may want to build up some goodwill and speed the thing up.