11

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.

Improve this question
4
  • Is there a non-functional requirement defined for the application start up or is this just a discussion within development?
    – StuperUser
    Oct 11, 2011 at 9:37
  • @StuperUser: no requirement, just a discussion so far.
    – JohnDoDo
    Oct 11, 2011 at 9:39
  • There is actually a User Experience site where this would be better asked.
    – Cyclops
    Oct 11, 2011 at 12:47
  • @Cyclops: I'm actually more interested in the reasons on the server side of the fence, not from the user side.
    – JohnDoDo
    Oct 11, 2011 at 13:23

5 Answers 5

Reset to default
18

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.

Improve this answer
4
  • Yes, I figured as much about the development cycle, but it's not like we change a comma, deploy, change a variable name, deploy etc. I personally deploy on development a max of 10 times/day. One minute startup or 1.2 ain't that much of a difference.
    – JohnDoDo
    Oct 11, 2011 at 9:37
  • 7
    @JohnDoDo: How much of that is really natural workflow and how much habitually avoiding a lengthy deployment? A quick feedback cycle can help productivity enormously. Sometimes making small, incremental changes and immediately seeing the result really is what you need. 50 years ago people wrote programs on paper, submitted them to an operator and got a printed result the next day - sometimes just a compiler error. Doesn't that seem like a horribly inefficient way to work to you? Well, to many programmers, your 10 deployments per day seem just like that.
    – Michael Borgwardt
    Oct 11, 2011 at 9:49
  • 1
    If possible, evaluate the option of doing a "mock" init, or of having the structures serialized to disk with test data to accelerate startup times during development.
    – Vinko Vrsalovic ♦
    Oct 11, 2011 at 11:47
  • I agree with Vinko, is there a way you can turn off the costly init() functions when building in Debug mode? Don't bother if what you are initializing will give you different results on Dev and Production, though.
    – AndyMcKenna
    Oct 11, 2011 at 20:33
4

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.

Improve this answer
2

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)

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
1
  • Web application startup time shouldn't be affecting normal users, though. The other developer is annoyed because he personally restarts the app multiple times as day as part of regular development.
    – AndyMcKenna
    Oct 11, 2011 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.