Thilo Planz wrote: > Hi, > >>>So I'm looking for an alternative mod_perl, and the two options seem > to be >>>FastCGI and Persistent Perl. Is there any reason to use one over the > other? >>>Have anyone used both, and has come to a conclusion about which is > best for >>>a C::A app? > > I have not used Persistent Perl, but FastCGI is quite stable in my > experience. > > The only problem I had was with the dynamic FastCGI process manager, > that would sometimes (say once a month) terminate all servers and not > bring them up again (Apache restart would fix that, and the problem does > not seem to occur with a static process manager). > >> I expect that they're all going to experience the same memory >> situation. They >> all operation on basically the same idea. (Though if anyone out there >> has a >> different perspective then I'd love to hear it. mod_perl is the only >> one of >> them I have extensive experience with.) > > > I think a big difference is that while you may need 50 httpd processes, > you most likely need much less FastCGI processes, so that it does not > matter that much if those three or four processes use a lot of memory.
Well you can (and probably should) do the same thing with mod_perl. Almost the first thing that the mod_perl guide suggests to do for performance is to put the mod_perl apache as a backend and have a light-weight apache (or other httpd server) as the front end. This also reduces the number of heavy and memory intensive mod_perl processes. > Another big difference is that FastCGI runs outside of the Apache > process and cannot bring Apache down. If you have more than one FastCGI > application, they are also separate from eachother. > So even if an coding error or runtime error causes one application to > run amok, the others (and the site as a whole) may still continue to > operate. You get the same thing with the frontend/backend split. >> Don't forget that, when you look at your Apache children's memory >> usage, much of >> the memory-bloat is shared so it's not really as bad as it looks at >> first. > > > I have heard, though, that Perl's memory pages have a tendency to become > "unshared" after some time. Memory will only get unshared if it's written to. So it's quite possible that there are a lot of modules out there that will change package level variables, etc and thus unshare a page. But I don't think this is a perl issue, but rather the author's of those modules not thinking about shared memory. -- Michael Peters Developer Plus Three, LP --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
