Karsten McMinn wrote:
On 5/9/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote:
I can now have two clients using 1000 parallel connections to one i386
850MHz server, my old one that I was testing with and I get all that no
problem now. No delay and I can even push it more, but I figure at 2000
parallel connections I should be able to get some breathing time now.
I've spent considerable time with tuning apache on openbsd to
consume all available resources in OpenBSD. Here's the
relevant httpd.conf sections:
Thanks. My configuration is more aggressive them yours and I can tell
you for a fact that the problem and limitations where not in the httpd
configuration, but in the OS part in my case anyway.
Some of your value I think would/could crash your system. Specially the:
MaxKeepAliveRequests 5000
MaxClients 5000
I don't think you could reach that high. Why, simply on a memory usage
stand point. That was my next exploration, but it's possible that one
apache process could take as much as 11MB
6035 www 2 0 11M 9392K sleep netcon 0:56 0.00% httpd
Obviously not all process would use that much. The question is really
depending on content. If small images and lots of them, then each
process use less memory. But if it is to serve all big files, then it's
possible to use a good amount of memory per process. Now I don't have
that answer here and I am not sure how to come with some logic on that,
but even if each process was using only 1MB, then 5000 would give you
5GB or RAM with is more then what OpenBSD was supporting until not so
long ago, so you will start to swap and god knows what will happen then.
So, I think the these two value are not realistic and safe to us.
Timeout 300
KeepAlive On
MaxKeepAliveRequests 5000
KeepAliveTimeout 15
I use KeepAliveTimeout 5 and I am considering to reduce it.
If you think aboiut your suggestion here, you have KeepAliveTimeout 15
and then MaxKeepAliveRequests 5000, don't you see the paradox here?
If your server is really busy, and lots of images on one page for
example, then you would have a lots of process stuck in KeepAliveTimeout
time out stage, so that's why you most likely increase your MaxClients
5000 to compensate for that, but that's wrong I believe. It makes your
server use more resources and be slower to react.
I use a logic here for the value on how to fix it.
MaxKeepAliveRequests I think should be set based on how many possible
additional requests a URL from a browser that support keep alive and
multiple requests at once could have. How many, well I think it's based
on how many elements your web page can have. That's the idea here isn't
it? Many browsers will call the URL and when images for example are on
that page they will fire up an additional request to the web server. So,
in theory the maximum number of requests you should allow should be the
maximum possible of elements one page could have on it no? Assuming a
users can click a few pages in a few seconds may be, I think anything
above 1000 is not good. I could be wrong, but that's how I see it. I use
250 and it serve me well and allow to protect the server from abuse from
one source. I have some setup that allow 100 max here for the
MaxKeepAliveRequests. But I would think that 1000 should be plenty and
more then that may not be good. Unless my thinking above is wrong?
I can do more tests on that to know more obviously.
For testing reason in my lab I put MaxKeepAliveRequests 0, but I
wouldn't use that in production for sure.
Your value may be good, I just think not, but that's open to discussion.
One thing for sure having the same number for MaxKeepAliveRequests and
for MaxClients, I think is wrong as you open yourself to have one
attacker from one source to bring your server down and huge it all for
himself. I believe that MaxKeepAliveRequests should definitely be lower
then your MaxClients, not the same for sure.
MinSpareServers 20
MaxSpareServers 30
StartServers 50
I also thing that if you want to run a so busy server, that you should
have more StartServers and for sure have a bigger margin between the min
and max as it will always kill process and start new one where as you
fork a lots and that's a pretty slow process and costly as well.Again
here I use some logic and based that on what the traffic is like. If you
allow multiple requests per connection, wouldn't it make sense for you
to be sure that you could serve that connection and all it's requests
without having to fork new process? Meaning if you have 50 elements on
your page, then it's possible that some browser will send you 50
requests, so why not make sure you have 50 minimum process to serve
them? Again, that's logical to me. I have some setup that I keep a
minimum of 50 spare and maximum of 100 spare. Not always, but some cases
yes. But it's better then the defautl one for sure. (;>
MaxClients 5000
To high I think based on the above explications. The risk of taking down
the server are to high to me, but I could be wrong. I think with a
properly setup server, 1000 is able to support a truck load of requests.
Most limitations were not find in the httpd setup in my tests and
regular operations. But again, I am open to discussion and exchange on
the subject.
MaxRequestsPerChild 0
I haven't seen any memory leak in httpd in a long time, so not have any
limits here is find. On Solaris however, you would want that, or use to
want that for sure.
I had staticlly compiled php into my httpd binary and obviously
raised HARD_LIMIT to 5000, using OpenBSD's apache.
I could have done that, but still run stock OpenBSD so module for now.
Yes there is definitely advantage to run static, but I try as much as
possible to run stock OS when possible for many reasons.
This netted me an ability to serve about a max of 3000
requests per second on a 1.6ghz athlon with 256MB of memory.
Your amount of memory really puzzle me here specially based on your
configuration and on what you say your traffic is like. How could you
possibly allow 5000 MaxClients with 256MB of memory??? Doesn't compute
to me really.
Best,
Daniel
