Big site architecture related things

[Edmund von der Burg]

On 10/11/2007, Lyle - CosmicPerl.com <perl at cosmicperl.com> wrote:
> The solution to my high traffic volume that I've been working toward
> doesn't use daemon's, although this is certainly making me re-consider.

One of the things that you will want to look at in your architecture
is where it blocks - that is to say that the execution of your code is
held up in some way. Good examples of blocking calls are writing to
databases and sending emails.

Of particular importance is to look at where these blocks are caused
by interactions with systems that you do not control - such as sending
email to other machines. If a remote SMTP server decides to go slow
then your code could be held up for a long time. Hence it is common to
send email by using a local mail handler such as qmail etc. In this
case your code sends the email to a local machine (usually localhost)
that you can rely on accepting the email quickly and so freeing up
your code. This other process is then responsible for sending on the
email, and dealing with timeouts, slow servers, hosts that are down
and all that crap.

You also need to look at the impact that blocking has. Say you are
writing a web app that deals with 10 requests per second, and
processes each request in 0.1 seconds. This would mean that you have
one process that can deal with the total load[0]. Now say that some
part of the request starts to block for a couple of seconds, such that
it takes 2.1 seconds to do each request[1]. You now need to have about
twenty processes running to keep up with the request rate. This mean
that the server will have more memory used and that the context
switching will start to kick in. At some point you'll hit swap and the
server will die.

Hence identify where your server blocks and ensure that those blocks
cannot kill you server. For this daemons tend to be very helpful.

Cheers,
  Edmund.


[0] - this is a simplification - but good enough for this example.
[1] - note that the blocking may not eat up more CPU - waiting for
network traffic is very efficient.