One reason why the Debian package format is not my favorite
In their wisdom, the people who created the Debian package format decided to allow packages to ask the person installing them questions. By including this feature, they insured that Debian packages do quiz the people installing them about various things.
The problem with this is that questions are landmines. Every time you ask one, you are gambling that the person knows enough about the issue to give you an informed answer. When they do not, at best they just pick the default answer (fortunately Debian seems to mostly insist that package questions have default answers) and you have just made them nervous.
Worse, every question that a Debian package asks is a decision the people building the package have pushed off to the people installing the package. Let's rephrase that: every question is a decision that the people who know the package best have deferred into the hands of people who are just installing it, perhaps merely because their users asked for it or they thought it sounded interesting.
The great advantage of package formats that do not allow install-time questions is that they force the people building packages to actually make decisions, not duck the issues.
(This entry is brought to you by the Ubuntu
ilisp package, which
felt it was burningly important to ask me whether it should use FSF
compliant keybindings or some other ones.)
A thought on web server capacity measurement
The traditional way of measuring how much load your web server can take
is to use a tool such as
ab to see how many requests a second you
can handle and how fast the requests get handled. People throw around
numbers such as their web server serves pages in 0.03 seconds under a
load of 50 simultaneous requests, for example.
(Sometimes they just say 0.03 seconds without mentioning important information like what sort of pages, on what sort of a system, and with how many simultaneous requests.)
In a way this is misleading, because real world load doesn't generally behave this way. In the real world, you don't have a certain number of simultaneous requests; instead you get a certain number of new requests every second, even if old requests haven't yet been dealt with.
In other words, the really interesting question is how many requests a second your website can handle, not how many it can handle at once. (Although how many it can handle at once is part of what determines how well it deals with load surges.)
The question I find myself mulling over is whether this makes any
practical difference most of the time. In a sense I think
ab is a
worst case, but only up to a point, and working out what that point is
seems a bit complicated.
ab does at least give you a requests per
second figure, so if you're using it the best approach is probably
to try a fairly large number of simultaneous connections and see if
the requests/second number still looks good.
The one thing such tools clearly can't do is tell you what happens when requests start arriving faster than you can process them and you go into an overload situation. Web servers can do a lot of different things under overload: they can go into a death spiral, dragging the entire machine down with them; they can start refusing connections; they can try to show visitors an error message. It's not necessarily predictable in advance, and what your web server actually does will determine how gracefully you handle sudden load surges.