[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