2014/01/09

Platform sizing 101

Today at work introducing a new database and application server were on the menu.

This was happening totally against my better judgement, but, somewhere, somehow, I came across an article on management which said "get things done, don't fuss too much how", and it's indeed probably a better way: we are getting things done in the spirit I had, let's just don't mind about the fussy details, things are evolving, and we're avoiding speeding up against a wall.
Enough about politics, to the real stuff now.

Sizing. We have n users. The literature around, I was told, says that the application server can handle n/2 users. Straightforward answer: we need two instances. Right. Wrong ?

Yes, that's the wrong answer. We care about user experience: if one server dies, or, more mundanely, one server is off for an update, the whole load goes to... well, that one server which can actually handle n/2 users. Oops.

Right, there's one way management likes, but users (and workers don't): take your service off and work at odd hours.

Or just setup three servers.

And there's a goodie along the way of that alternative scenario: when your load increases, you get more time to add another one before user experience deteriorates.