Re[2]: Memory requirements for web-project

Hello Lincoln,

Sunday, February 04, 2001, 5:51:37 PM, you wrote:

LY> At 05:10 PM 2/4/01 +0100, Boris wrote:
>>160.000 hits are wanted, so I calculate 160.000 div 24 = approx 6666
>>Hits a hour, div 60 = 111 Hits a minute, = 1,85 Hits per secound.
>>
>>lets round it up to 2 hits per secound. So I calculate now
>>2 hits per second * 3 seconds for a client
>>= 6 processes at the same time,
>>
>>is that correct?

LY> My guess is that your hits are likely to bunch up at certain times, rather
LY> than be spread out evenly (90% of the people behave similarly 90% of the
LY> time). So you might wish to multiply by 5 or 10 (or whatever you pluck from
LY> the air ;) ) to cater for peak load.

LY> Why are you saying it takes 3 seconds for a client? If it's because the
LY> client is slow, you can do something about that, but if it's because your
LY> query takes 3 seconds then maybe some people here could help with your query.

>>If so, how much is the memory requiremend? I have seen with "TOP" that
>>pgsql requires 5000kb for a request, but it is used per client (new
LY> processes

LY> The minimum size varies depending on what platform it's running on.

LY> The max seems to vaguely depend on the size of the result set. But usually
LY> most of the mem is reclaimed after the query is finished, at least on my
LY> system.

LY> Just do some tests with your bigger queries.

LY> I'd say go for 512MB RAM.

LY> Coz, usually you can't add RAM during peak load, and if you can, it usually
LY> means you have hardware where 1GB or more is minimum anyway ;).

LY> And you might be able to stick half on another server (web+app) if
LY> desperate :).

LY> Cheerio,
LY> Link.

Hello Lincoln,

Sunday, February 04, 2001, 5:51:37 PM, you wrote:

LY> At 05:10 PM 2/4/01 +0100, Boris wrote:
>>160.000 hits are wanted, so I calculate 160.000 div 24 = approx 6666
>>Hits a hour, div 60 = 111 Hits a minute, = 1,85 Hits per secound.
>>
>>lets round it up to 2 hits per secound. So I calculate now
>>2 hits per second * 3 seconds for a client
>>= 6 processes at the same time,
>>
>>is that correct?

LY> My guess is that your hits are likely to bunch up at certain times, rather
LY> than be spread out evenly (90% of the people behave similarly 90% of the
LY> time). So you might wish to multiply by 5 or 10 (or whatever you pluck from
LY> the air ;) ) to cater for peak load.

Ah, very interesting, yes - I forgot!

LY> Why are you saying it takes 3 seconds for a client? If it's because the

No its a server problem, has nothing to do with the database -)

LY> The minimum size varies depending on what platform it's running on.

Aha, interesting.

LY> The max seems to vaguely depend on the size of the result set. But usually
LY> most of the mem is reclaimed after the query is finished, at least on my
LY> system.

Interesting to know.

LY> Just do some tests with your bigger queries.

Ok, good idea.

LY> I'd say go for 512MB RAM.

That sounds good, the only question left is the memory requiremend of
apache per client, i do not completely understand the spawning things
with Apache. On high load there are alway minimum 10 processes left,
but where is the limit? Interesting thing.

LY> Coz, usually you can't add RAM during peak load, and if you can, it usually
LY> means you have hardware where 1GB or more is minimum anyway ;).

LY> And you might be able to stick half on another server (web+app) if
LY> desperate :).

ok.

LY> Cheerio,
LY> Link.

Thanks, that helped a lot!

--
Boris
www.x-itec.de

--
Boris [MCSE, CNA]
...................................................................
X-ITEC : Consulting * Programming * Net-Security * Crypto-Research
........: [PRIVATE ADDRESS:]
: Boris Köster eMail koester(at)x-itec(dot)de http://www.x-itec.de
: Grüne 33-57368 Lennestadt Germany Tel: +49 (0)2721 989400
: 101 PERFECTION - SECURITY - STABILITY - FUNCTIONALITY
........:..........................................................

Everything I am writing is (c) by Boris Köster and may not be
rewritten or distributed in any way without my permission.