[Gllug] how much memory

Doug Winter doug at pigeonhold.com
Mon Sep 22 09:41:43 UTC 2003


On Sun 21 Sep Sean Burlington wrote:
> 0.5 million hits per month - mostly php/mysql

For your specific case, I'd say 500,000 hits/month is very little
traffic, and you should be able to run that on almost anything.

Here is some stuff that I have gleaned from trying to predict
performance.  I may have it all arse-backwards, so apologies if it's
completely wrong :)

In general, memorywise, your optimum configuration is to not swap.  This
means you need to know the memory usage of each process, and how many of
these processes you need to run to service your requests.

For apache on Linux, "top" shows these figures for an httpd process:

    Size:  8724K 
    RSS:   8552K 
    Share: 7332K

What these mean is:

    size - the memory mapped by the process.  this is largely
    meaningless.

    rss - "Resident Set Size" -- the amount of memory actually resident
    in memory.  This includes the memory shared by other processes.

    share - the amount of memory from the RSS that is used by the
    application.

the actual memory used by this process only is RSS - SHARE.  In the case
of the httpd process above this is 8552-7332 = 1220K, or almost exactly
1Mb.

The number of httpd processes you need to run in parallel will depend on
your actual usage distribution.  Some general rules of thumb are:

    peak traffic =   3 x mean
    spike traffic = 10 x mean

Peak traffic is just the effect of a standard statistical distribution -
most peoples traffic graphs have the same general shape, and the peak is
generally 3 times the mean.  

You will definately need to be able to service peak traffic.  Depending
on your business you may need to service spike traffic.  Spike traffic
is generally caused by things outside your immediate control, like PR
launches and what have you.

So for you, assuming your traffic is limited to an 8 hour day:

    500,000 / ( 364 / 12 * 8 ) = 500,000 / 242 = 2066 hits/hour
    2066 hits/hour = 0.574 hits/second

To determine how many parallel processes are required to service this
request, you need to know your service time.  This is the average time
taken to service a request - i.e. if you only have one request and one
server, how long does it take to service it?  This is something you can
measure.  Lets assume it is 4 seconds.

You have 0.574 hits/second arriving, and each one takes 4 seconds.  So
you will have at any one time 4 * 0.574 requests being serviced (on
average).  This is 2.296 requests.  This means you need, on average,
2.296 httpd processes.  For peak traffic you need 3 times this, or 6.887
apache processes.

The apache sizing figures above tell us that apache memory usage equals:

    M = 7332 + 1220 * p

Where p is the number of processes.  With a p of 6.887, this comes to:

    M = 15734K = 15Mb

This is the footprint of the apache processes you require.  Obviously
this is significantly dependent on the service time.  Also, obviously,
it's only really a wild guess, since your processing model also needs to
take into account network buffers, mysql, and all sorts of other stuff.

Wild guesses are generally sufficient however :)

If you want to read further I can recommend:

    The Practical Performance Analyst, 
        Neil J Gunther, 0-595-12674-X
        
    The Art of Computer Systems Performance Analysis, 
        Raj Jain, 0-471-50336-3

Cheers,

Doug.
 
-- 
6973E2CF print 2C95 66AD 1596 37D2 41FC  609F 76C0 A4EC 6973 E2CF
"If you are the type of person who likes assault weapons, there
is a place for you - the United States Army. We have them."
   -- General Wesley Clark, responding to a question on gun control

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20030922/12f87af7/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug


More information about the GLLUG mailing list