From trevormg19 at gmail.com Thu Dec 6 12:22:00 2007 From: trevormg19 at gmail.com (Trevor Little) Date: Thu, 6 Dec 2007 15:22:00 -0500 Subject: [Raleigh-talk] mod_perl 2.0, mpm_worker, and ithreads Message-ID: <944d53050712061222n433f8e1lbe0a733efad063b9@mail.gmail.com> Hey everybody, I'm hopping someone can lend me some experience with mod_perl 2.0, mpm_worker, and ithreads. Specifically, I'm trying to decide the best way to deploy mod_perl in a production environment and after reading through all the documentation I could absorb today, I'm still left with some questions. I should mention first that none of the code we've written uses threads, I'm just trying to figure out the benefits/disadvantages to running in a threaded mod_perl environment with mpm_worker. 1. How do I know if a cpan module I use is thread-safe? Is there any way to know for sure without reading all the code myself? We use a lot of CPAN modules and having to go back and check each one for thread safety, re-implementing the ones that are not, would keep me away from ithreads for now. 2. Some of our cgi scripts override signal handlers and fork their own children. Is that going to play nice in a threaded environment break things? 3. Is there a performance benefit to running mod_perl with mpm_worker if almost all requests to the server will be to a cgi application? I've read people who've said that perl's memory usage with threads is worse than with pre-fork, and I've read documentation that seems to imply the opposite. Obviously that's a lot of questions and I'm not expecting anybody to give me a free in-depth course on perl threads. However, if you've used mod_perl with mpm_worker, I'd love to hear how it worked out for you and weather youd recommend it. Thanks in advance. Trevor From james.oden at gmail.com Thu Dec 6 13:22:14 2007 From: james.oden at gmail.com (James Olin Oden) Date: Thu, 6 Dec 2007 16:22:14 -0500 Subject: [Raleigh-talk] mod_perl 2.0, mpm_worker, and ithreads In-Reply-To: <944d53050712061222n433f8e1lbe0a733efad063b9@mail.gmail.com> References: <944d53050712061222n433f8e1lbe0a733efad063b9@mail.gmail.com> Message-ID: On Dec 6, 2007 3:22 PM, Trevor Little wrote: > Hey everybody, > > I'm hopping someone can lend me some experience with mod_perl 2.0, > mpm_worker, and ithreads. Specifically, I'm trying to decide the best > way to deploy mod_perl in a production environment and after reading > through all the documentation I could absorb today, I'm still left > with some questions. I should mention first that none of the code > we've written uses threads, I'm just trying to figure out the > benefits/disadvantages to running in a threaded mod_perl environment > with mpm_worker. > > 1. How do I know if a cpan module I use is thread-safe? Is there any > way to know for sure without reading all the code myself? We use a lot > of CPAN modules and having to go back and check each one for thread > safety, re-implementing the ones that are not, would keep me away from > ithreads for now. > If they say they are in their documentation. Otherwise its likely that they are but YMMV. > 2. Some of our cgi scripts override signal handlers and fork their own > children. Is that going to play nice in a threaded environment break > things? > Not according to the perlthrtut man page...look for fork() within it. That said, I have done it and it seems to work. > 3. Is there a performance benefit to running mod_perl with mpm_worker > if almost all requests to the server will be to a cgi application? > I've read people who've said that perl's memory usage with threads is > worse than with pre-fork, and I've read documentation that seems to > imply the opposite. > Read the perlthrtut man page, but the bottom line is that for each thread a whole new perl interpret gets created. This is why its called ithread (interperter Threads). Thats an expensive operation. OTOH if you do this at start or not so often its not so bad. In the particular case of mod_perl you may want to look towards a mod_perl list or perhaps their docos. Cheer...james P.S. I have used ithreads for production app written from the ground up but I have not used mod_perl. From trevormg19 at gmail.com Fri Dec 7 05:59:05 2007 From: trevormg19 at gmail.com (Trevor Little) Date: Fri, 7 Dec 2007 08:59:05 -0500 Subject: [Raleigh-talk] mod_perl 2.0, mpm_worker, and ithreads In-Reply-To: References: <944d53050712061222n433f8e1lbe0a733efad063b9@mail.gmail.com> Message-ID: <200712070859.05633.trevormg19+raleigh-talk@gmail.com> James, Thanks for the quick response. I think that ultimately ithreads could work for us but not with out code as it stands now. It was good to get some insight from someone who's worked with threads in perl. I hope to eventually replace some of the forking I'm doing with threads and is seems a bit cleaner, until then I guess we'll stick with the per-fork model. Thanks again, Trevor On Thursday 06 December 2007 04:22:14 pm James Olin Oden wrote: > On Dec 6, 2007 3:22 PM, Trevor Little wrote: > > Hey everybody, > > > > I'm hopping someone can lend me some experience with mod_perl 2.0, > > mpm_worker, and ithreads. Specifically, I'm trying to decide the best > > way to deploy mod_perl in a production environment and after reading > > through all the documentation I could absorb today, I'm still left > > with some questions. I should mention first that none of the code > > we've written uses threads, I'm just trying to figure out the > > benefits/disadvantages to running in a threaded mod_perl environment > > with mpm_worker. > > > > 1. How do I know if a cpan module I use is thread-safe? Is there any > > way to know for sure without reading all the code myself? We use a lot > > of CPAN modules and having to go back and check each one for thread > > safety, re-implementing the ones that are not, would keep me away from > > ithreads for now. > > If they say they are in their documentation. Otherwise its likely > that they are but YMMV. > > > 2. Some of our cgi scripts override signal handlers and fork their own > > children. Is that going to play nice in a threaded environment break > > things? > > Not according to the perlthrtut man page...look for fork() within it. > That said, I have done it and it seems to work. > > > 3. Is there a performance benefit to running mod_perl with mpm_worker > > if almost all requests to the server will be to a cgi application? > > I've read people who've said that perl's memory usage with threads is > > worse than with pre-fork, and I've read documentation that seems to > > imply the opposite. > > Read the perlthrtut man page, but the bottom line is that for each > thread a whole new perl interpret > gets created. This is why its called ithread (interperter Threads). > Thats an expensive operation. OTOH if you do this at start or not so > often its not so bad. > > In the particular case of mod_perl you may want to look towards a > mod_perl list or perhaps their docos. > > Cheer...james > > P.S. I have used ithreads for production app written from the ground > up but I have not used mod_perl. > _______________________________________________ > Raleigh-talk mailing list > Raleigh-talk at pm.org > http://mail.pm.org/mailman/listinfo/raleigh-talk