[Van-pm] Question about handling multiple clients

Kevin Scaldeferri kevin at scaldeferri.com
Fri Mar 31 11:34:25 PST 2006


On Mar 31, 2006, at 10:43 AM, Heng Ha wrote:

> thanks for the reply, it works faster and better than
> before :-)
>
> however, I want it to do something like :
>
> provided that I pre-forked 100 children and 500
> concurrent requests come in, now by printing out the
> counter it seems works 100 by 100, not 500 in ,
> listening, process at the same time, then finish at
> the same time.
>
> so server should have max_requests_per_child *
> pre-forked children listening the requests once the it
> is up , in other words, 5 * pre-forked 100 = 500
> listening , then when 500 requests flooded-in, server
> should processes all at once, not 100 by 100,
>
> any idea ? thanks

Okay, so you seriously don't want 100 children trying to do work 
simultaneously, and 500 is right out.  The context switching overhead 
is going to kill your performance.

You need to be thinking about what your performance requirements are 
under high load.  Are you trying to maximize throughput?  Minimize 
latency?  Minimize user-perceived latency?  Prevent connection 
timeouts?

Assuming your "work" is mostly CPU, the highest throughput will 
typically be achieved by only having as many worker children as you 
have processors.  In this case, connections will pile up, but assuming 
they don't exceed your maximum throughput, you'll get to them all, 
it'll just take longer.

If you spend part of your time blocking on I/O, you can increase the 
number of workers in proportion to the ratio of CPU to I/O time.

If you really need to accept connections in a short time after they 
arrive (either to prevent timeouts or to get some partial output back 
to the user's screen quickly), then you'll get better overall 
performance if you keep the number of children small, but structure 
your processing so that you can multiplex requests in a single process. 
  Again, POE provides you with a pretty good framework for doing this, 
although if your processing is simple enough, you can implement the 
state machine by hand.


-kevin




>
> --- Kevin Scaldeferri <kevin at scaldeferri.com> wrote:
>
>>
>> On Mar 31, 2006, at 9:02 AM, Heng Ha wrote:
>>
>>> Hello everyone,
>>>
>>>    I am coding a daemon which should handle
>> multiple
>>> clients.
>>>
>>>    I referenced the pre-forking server code in
>> Perl
>>> cookbook that pre-forks several child processes
>> and
>>> each of them handle multiple requests.
>>>
>>>    The problem I got now is in the code the
>> counter
>>> calculates the number of incoming requests never
>>> increments.
>>
>> The problem is that accept() will almost always
>> return a true value, so
>> that while loop never exits.  You don't have a
>> timeout, so the only
>> reason it should ever fail is if the local socket is
>> closed for some
>> reason or something borks the networking.
>> Otherwise, it just blocks
>> until a connection comes in.
>>
>> To get the effect you want, you should combine the
>> outer two loops or
>> just get rid of the accept loops and do
>>
>>    $client = $server->accept() or last;
>>
>> which is actually what my copy of the cookbook has
>> in this example.
>>
>>
>>
>>>
>>>    The code is the following and can any one give
>> me a
>>> hand ? also, if possible, anyone has experience
>> with
>>> thread programming in perl, is that production
>> ready ?
>>
>> Don't do it.
>>
>> If you need thread-like parallelism, POE is a much
>> better idea.
>>
>>>
>>>           # handle connections until we've reached
>>> $MAX_CLIENTS_PER_CHILD
>>>           for ($i=0; $i < $MAX_CLIENTS_PER_CHILD;
>>> $i++)      {
>>>              while ( $client = $server->accept( )
>> )
>>>                   {
>>>                     while ( <$client> )
>>>                       {
>>>                        #do something like print
>>> $client....
>>>
>>>                       }
>>>
>> $client->shutdown(SHUT_RDWR);
>>>                   }
>>>               # do something with the connection
>>>           }
>>>
>>
>>
>>
>> -kevin
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com



More information about the Vancouver-pm mailing list