From lukec at ActiveState.com Wed Mar 8 12:05:39 2006 From: lukec at ActiveState.com (Luke Closs) Date: Wed, 8 Mar 2006 12:05:39 -0800 Subject: [Van-pm] March Meeting In-Reply-To: <20060228185110.GL1333@soundwave.net> References: <20060228185110.GL1333@soundwave.net> Message-ID: <20060308200539.GA24594@activestate.com> On Tue, Feb 28, 2006 at 10:51:10AM -0800, Helen Cook wrote: > Also we need a date. Let's say Wednesday, March 22nd assuming the mez > is free (Luke, would you please check and book it if available?) Not available on the 22nd. Another date? If we don't have any other presentations, maybe we could postpone for a month. My selenium stuff won't be too crazy. Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone. From hengha2002 at yahoo.com Fri Mar 31 09:02:50 2006 From: hengha2002 at yahoo.com (Heng Ha) Date: Fri, 31 Mar 2006 09:02:50 -0800 (PST) Subject: [Van-pm] Question about handling multiple clients Message-ID: <20060331170250.73328.qmail@web32503.mail.mud.yahoo.com> 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 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 ? I am using Perl 5.8.7 on Linux and here is the snippet about that counter, thanks : #the counter is the i in this for loop #for ($i=0; $i < $MAX_CLIENTS_PER_CHILD; $i++) #it never increments , if it does , how to verify #multiple requests handled by one child ? use IO::Socket; use POSIX; if ($pid) { # Parent records the child's birth and returns. sigprocmask(SIG_UNBLOCK, $sigset) or die "Can't unblock SIGINT for fork: $!\n"; $children{$pid} = 1; $children++; return; } else { # Child can *not* return from this subroutine. $SIG{INT} = 'DEFAULT'; # make SIGINT kill us as it did before # unblock signals sigprocmask(SIG_UNBLOCK, $sigset) or die "Can't unblock SIGINT for fork: $!\n"; # 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 } # tidy up gracefully and finish # this exit is VERY important, otherwise the child will become # a producer of more and more children, forking yourself into # process death. exit; } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kevin at scaldeferri.com Fri Mar 31 10:06:42 2006 From: kevin at scaldeferri.com (Kevin Scaldeferri) Date: Fri, 31 Mar 2006 10:06:42 -0800 Subject: [Van-pm] Question about handling multiple clients In-Reply-To: <20060331170250.73328.qmail@web32503.mail.mud.yahoo.com> References: <20060331170250.73328.qmail@web32503.mail.mud.yahoo.com> Message-ID: <3a6942b554e178e2438b81aeb5607274@scaldeferri.com> 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 From jessesherlock at gmail.com Fri Mar 31 10:18:06 2006 From: jessesherlock at gmail.com (Jesse Sherlock) Date: Fri, 31 Mar 2006 10:18:06 -0800 Subject: [Van-pm] Question about handling multiple clients In-Reply-To: <3a6942b554e178e2438b81aeb5607274@scaldeferri.com> References: <20060331170250.73328.qmail@web32503.mail.mud.yahoo.com> <3a6942b554e178e2438b81aeb5607274@scaldeferri.com> Message-ID: <5d9c14080603311018h5beee04bx5fa0606619b4307a@mail.gmail.com> If you like the API for threads, have a look at the forks libraries in cpan, they look like perl threads (you may consider this good or bad) but use fork. Threads are definitely not production ready in perl. cheers, Jesse On 3/31/06, Kevin Scaldeferri 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 > > _______________________________________________ > Vancouver-pm mailing list > Vancouver-pm at pm.org > http://mail.pm.org/mailman/listinfo/vancouver-pm > From kevin at scaldeferri.com Fri Mar 31 11:34:25 2006 From: kevin at scaldeferri.com (Kevin Scaldeferri) Date: Fri, 31 Mar 2006 11:34:25 -0800 Subject: [Van-pm] Question about handling multiple clients In-Reply-To: <20060331184317.45001.qmail@web32504.mail.mud.yahoo.com> References: <20060331184317.45001.qmail@web32504.mail.mud.yahoo.com> Message-ID: <7bfe54f0662bb523c48c0964fb8e7892@scaldeferri.com> 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 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 From mock at obscurity.org Fri Mar 31 15:40:47 2006 From: mock at obscurity.org (mock) Date: Fri, 31 Mar 2006 23:40:47 +0000 Subject: [Van-pm] Question about handling multiple clients In-Reply-To: <3a6942b554e178e2438b81aeb5607274@scaldeferri.com> References: <20060331170250.73328.qmail@web32503.mail.mud.yahoo.com> <3a6942b554e178e2438b81aeb5607274@scaldeferri.com> Message-ID: <20060331234047.GW27377@obscurity.org> On Fri, Mar 31, 2006 at 10:06:42AM -0800, Kevin Scaldeferri wrote: > If you need thread-like parallelism, POE is a much better idea. > POE would solve the problem. You might also want to look at my Apache2::TieBucketBrigade module which lets you use mod_perl as your daemon framework. The other module you might want to look into, is Event::Lib, a framework based on top of libevent. Neither of the last two provide threads, but I've found that most often when writing a daemon you don't really want that anyway. will From hengha2002 at yahoo.com Fri Mar 31 17:38:43 2006 From: hengha2002 at yahoo.com (Heng Ha) Date: Fri, 31 Mar 2006 17:38:43 -0800 (PST) Subject: [Van-pm] Question about handling multiple clients In-Reply-To: <20060331234047.GW27377@obscurity.org> Message-ID: <20060401013843.9228.qmail@web32504.mail.mud.yahoo.com> Hi Mock, Thanks a lot, I will check it out :-) --- mock wrote: > On Fri, Mar 31, 2006 at 10:06:42AM -0800, Kevin > Scaldeferri wrote: > > If you need thread-like parallelism, POE is a much > better idea. > > > > POE would solve the problem. You might also want to > look at my > Apache2::TieBucketBrigade module which lets you use > mod_perl as your daemon > framework. The other module you might want to look > into, is Event::Lib, a > framework based on top of libevent. Neither of the > last two provide threads, > but I've found that most often when writing a daemon > you don't really want > that anyway. > > will > _______________________________________________ > Vancouver-pm mailing list > Vancouver-pm at pm.org > http://mail.pm.org/mailman/listinfo/vancouver-pm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com