On Wed, 2009-06-10 at 09:10 -0700, Vinay Nagrik wrote: > Dear Group, > > How do web servers achieve scalability is bothering me for a long > time. My understanding is that an application can open one and only > one socket connection through four system calls (socket, bind, listen, > and accept). It is at 'listen' level that a server can specify for > how many connection can queue up on that connection and my > understanding is that subsequent requests will be queued up and no > concurrency will be achieved, thus defeating the purpose of > scalability. > > Q. 1. Can some one tell me how many connections in present > Unix/Linux OSes a server can queue up. > > While reading some literature on http server, I came across the > following that in > > "1.3.x, the server can allow 150 client connections and in 2.0 version > the server can create 50 "threadsperchild". > > Both parameters in different versions are configurable i.e. (150 > client connections or 50 threadsperchild). > > Q. 2. What exactly is client connection. My understanding is that 150 > 'connect' system calls will queue up on the same SINGLE socket and no > concurrency can be achieved. > > Q. 3. I also do not understand the 'threadsperchild.' In this case > what constitutes a Child and what will each thread's task is. > > Can someone who knows about this issue please shed some light on it. > > Thanks in advance. > > -- > Thanks > > Nagrik > TCP queue lengths are dependent upon OS. Check the documentation for your OS for details. Google for '<os name> listen queue length'. The 'some literature' you read is incorrect, in all versions of apache these things are configurable. Read http://httpd.apache.org/docs/2.2/mpm.html In prefork MPM, the listening socket is held by the master httpd process. It accepts a connection, and then hands it off to a child to perform the work. The child is a fork() of the main httpd process, and the limit on the number of child workers is controlled by the directive MaxClients. Each child handles exactly one client, from reading the request, generating the response, logging the response, and then goes back to waiting for more work from the parent. Prefork mode exists in both apache 1.3 and 2.x (in 1.3 iirc it is called perchild, but the effect is the same). ThreadsPerChild has no meaning with the prefork MPM. In apache 2.x, there are other, threaded, MPMs - worker and event. Each of these work in slightly different manners. Worker works like prefork, except each child process has a number of worker threads which are used to handle requests, in a similar manner as prefork. Event works slightly differently, it has generic worker threads, but it also has event-specific threads, eg for waiting for new requests to be made on a keep-alive connection. These event specific threads save resources, as one thread can handle waiting for many keep alive connections (where as in prefork mode, an entire child is utilised to handle a single keep-alive connection). For the threaded MPMs, you have up to MaxClients threads. The maximum number of active child processes is determined by the MaxClients directive divided by the ThreadsPerChild directive. BTW, large chunks of this I have literally copy pasted out of 'THE MANUAL'. Read it, repeatedly, until it makes sense. If it doesn't make sense, then for sure, come back and ask for more details, but this is documented in detail on the worker MPM page: http://httpd.apache.org/docs/2.2/mod/worker.html Cheers Tom --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|