RE: [Catalyst] Why use external FastCGI apps?
-Original Message- From: Matt S Trout [mailto:[EMAIL PROTECTED] Sent: Sunday, April 06, 2008 12:01 PM To: The elegant MVC web framework Subject: Re: [Catalyst] Why use external FastCGI apps? On Mon, Mar 10, 2008 at 10:47:01AM -0400, Matt Pitts wrote: I'm honored by the invitation and I got my boss to OK it. So where should it exist in the Wiki and what should it be called? PAR Deployments w/ Apache and FastCGI? Sounds good. To be entirely honest, I don't so much care where it goes so long as it's there - a mis-placed article can be moved but a nonexistant one is no use at all :) Roger that. It's there, but I haven't had the time to work on it much the last month. It will get finish, however, one way or another. Actually, I'm working now to get my Makefile.PL nailed down so that all my dependencies actually get pulled into the PAR so that the app can be run on a fresh system with a minimal number of CPAN installs - hopefully, only parl. I might write up another post on this to get some more input. v/r -matt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
On Mon, Mar 10, 2008 at 10:47:01AM -0400, Matt Pitts wrote: I'm honored by the invitation and I got my boss to OK it. So where should it exist in the Wiki and what should it be called? PAR Deployments w/ Apache and FastCGI? Sounds good. To be entirely honest, I don't so much care where it goes so long as it's there - a mis-placed article can be moved but a nonexistant one is no use at all :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
On 10 Mar 2008, at 14:47, Matt Pitts wrote: -Original Message- From: Matt S Trout [mailto:[EMAIL PROTECTED] Neat approach. Thanks again for all the input. Any chance you could repay in kind by writing up what you ended up with on the wiki? Using PAR + external fcgi this way is an interesting deployment option and I think people would be interested in the process - if nothing else the work you did to get your PAR built would be worth showing off. I'm honored by the invitation and I got my boss to OK it. So where should it exist in the Wiki and what should it be called? PAR Deployments w/ Apache and FastCGI? The wiki (and where I'd put your page) is here: http://catwiki.toeat.com/gettingstarted/tutorialsandhowtos The wiki uses a standard wiki syntax for links, and Markdown as the 'markup' language.. Cheers Tom ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
On Mon, Feb 25, 2008 at 09:35:04AM -0500, Matt Pitts wrote: -Original Message- From: Matt S Trout [mailto:[EMAIL PROTECTED] Sent: Saturday, February 23, 2008 1:18 PM To: The elegant MVC web framework Subject: Re: [Catalyst] Why use external FastCGI apps? On Tue, Feb 19, 2008 at 09:58:05AM -0500, Matt Pitts wrote: -Original Message- From: Matt Pitts [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 11:47 AM To: [EMAIL PROTECTED]; The elegant MVC web framework Subject: RE: [Catalyst] Why use external FastCGI apps? Although I haven't had any experience yet with *external* fastcgi, I'm feeling this approach as well, mainly because it allows me to hang my hat on the starting/stopping/reloading of apache. I'm also trying to treat an Apache vhost like an appliance that I can drop anywhere. I basically have *everything* related to a single vhost organized under a standard structure and I keep it all in Subversion. This way, deploying a site to a different machine is - get vhost appliance from subversion - symlink vhost conf file into apache vhosts.d - sync logs if necessary - apache reload I know my model isn't perfect, but if I use external fastcgi then it adds an easily looked over step - create/symlink some fastcgi init script. The only things that will definitively push the use of external fastcgi are: if I cannot get mod_fcgid to work with PAR files; or if I'm happy with external fastcgi testing/memory usage and can integrate it into my vhost model without too much unhappiness. Well, external FCGI ended up winning me over, mainly because I couldn't get mod_fcgid to launch from a PAR. However, I must confess that I don't mind the approach now as I have built init scripts and organized things so that they are sane to me. As Yuval said, this does reduce the config mess. If anyone is interested here is my setup... - Apache 2.2 proxy frontend w/ proxy_balancer and its manager interface; mod_cband for throttling and its live traffic interface - 2 Apache 2.2 backends each doing static file serving and external FCGI to local Cat apps When I do updates I just use the proxy_balancer manager interface to disable the host I'm going to update and do the switch-a-roo. Part of the point of using external to me is not needing that stage - I bring up a new external FCGI, change an apache config symlink to point to the new one, apachectl graceful then shut down the old external FCGI. At no point is the node not serving requests, which can be extremely handy if you're heavily loaded. Also means you can flip all servers across simultaneously, which can be important for some updates. Yes, I quickly realized the limitation with my setup and rewrote my FCGI init script to have a simple versioning scheme. Each time it's run as fcgi.init start it actually starts up a brand new instance from the PAR (new PAR temp folder, new socket) and then does ls -sf to repoint the ExternalFCGI socket to the new version. When it's called as fcgi.init restart is does fcgi.init start; fcgi.init stop-previous which DWIM. I realize this may not be as sane as rewriting the apache config to point to the new socket, but it's working well for me. I've run some rudimentary tests against it with ab and with a concurrency of 5 during the fcgi.init restart process I've only gotten one failed request in my tests. One day I'll probably get annoyed with it and rewrite it again to update the apache config rather than just overwrite the socket symlink, but for now it works for me. Neat approach. Thanks again for all the input. Any chance you could repay in kind by writing up what you ended up with on the wiki? Using PAR + external fcgi this way is an interesting deployment option and I think people would be interested in the process - if nothing else the work you did to get your PAR built would be worth showing off. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
On Tue, Feb 19, 2008 at 09:58:05AM -0500, Matt Pitts wrote: -Original Message- From: Matt Pitts [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 11:47 AM To: [EMAIL PROTECTED]; The elegant MVC web framework Subject: RE: [Catalyst] Why use external FastCGI apps? Although I haven't had any experience yet with *external* fastcgi, I'm feeling this approach as well, mainly because it allows me to hang my hat on the starting/stopping/reloading of apache. I'm also trying to treat an Apache vhost like an appliance that I can drop anywhere. I basically have *everything* related to a single vhost organized under a standard structure and I keep it all in Subversion. This way, deploying a site to a different machine is - get vhost appliance from subversion - symlink vhost conf file into apache vhosts.d - sync logs if necessary - apache reload I know my model isn't perfect, but if I use external fastcgi then it adds an easily looked over step - create/symlink some fastcgi init script. The only things that will definitively push the use of external fastcgi are: if I cannot get mod_fcgid to work with PAR files; or if I'm happy with external fastcgi testing/memory usage and can integrate it into my vhost model without too much unhappiness. Well, external FCGI ended up winning me over, mainly because I couldn't get mod_fcgid to launch from a PAR. However, I must confess that I don't mind the approach now as I have built init scripts and organized things so that they are sane to me. As Yuval said, this does reduce the config mess. If anyone is interested here is my setup... - Apache 2.2 proxy frontend w/ proxy_balancer and its manager interface; mod_cband for throttling and its live traffic interface - 2 Apache 2.2 backends each doing static file serving and external FCGI to local Cat apps When I do updates I just use the proxy_balancer manager interface to disable the host I'm going to update and do the switch-a-roo. Part of the point of using external to me is not needing that stage - I bring up a new external FCGI, change an apache config symlink to point to the new one, apachectl graceful then shut down the old external FCGI. At no point is the node not serving requests, which can be extremely handy if you're heavily loaded. Also means you can flip all servers across simultaneously, which can be important for some updates. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Why use external FastCGI apps?
-Original Message- From: Matt Pitts [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 11:47 AM To: [EMAIL PROTECTED]; The elegant MVC web framework Subject: RE: [Catalyst] Why use external FastCGI apps? Although I haven't had any experience yet with *external* fastcgi, I'm feeling this approach as well, mainly because it allows me to hang my hat on the starting/stopping/reloading of apache. I'm also trying to treat an Apache vhost like an appliance that I can drop anywhere. I basically have *everything* related to a single vhost organized under a standard structure and I keep it all in Subversion. This way, deploying a site to a different machine is - get vhost appliance from subversion - symlink vhost conf file into apache vhosts.d - sync logs if necessary - apache reload I know my model isn't perfect, but if I use external fastcgi then it adds an easily looked over step - create/symlink some fastcgi init script. The only things that will definitively push the use of external fastcgi are: if I cannot get mod_fcgid to work with PAR files; or if I'm happy with external fastcgi testing/memory usage and can integrate it into my vhost model without too much unhappiness. Well, external FCGI ended up winning me over, mainly because I couldn't get mod_fcgid to launch from a PAR. However, I must confess that I don't mind the approach now as I have built init scripts and organized things so that they are sane to me. As Yuval said, this does reduce the config mess. If anyone is interested here is my setup... - Apache 2.2 proxy frontend w/ proxy_balancer and its manager interface; mod_cband for throttling and its live traffic interface - 2 Apache 2.2 backends each doing static file serving and external FCGI to local Cat apps When I do updates I just use the proxy_balancer manager interface to disable the host I'm going to update and do the switch-a-roo. I realize it's not perfect because it relies on my mouse clicking, so I may still end up writing a script to do the switching at the FCGI app, but this works for now. I'd really love to hack up a patch to mod_proxy that allows you to switch one backend on and another one off at the same time. The next thing I'd like to implement is database load balancing so that I'm not locked into a single database system. This will probably be another thread. Thanks to all of you who gave input to this one. v/r -matt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
I experienced similar behavior with Catalyst when using external FastCGI controlled by init.d under two FC8 boxes. When the app was restarted, it never came back. The processes were still there, but the socket became non-responsive. Issuing another start command would bring up another copy of the app that worked, but the old processes were still running on the system and eventually caused the running live app to come to a crawl. This lead to a daily purge cycle where, in the mornings before users started hitting the system, I would stop the app and then check the process list for any app processes still hanging around and kill them. Generally, only kill -9 would do the trick. On really busy days, I might have to do this purge process later in the afternoon as well. And after a few weeks, no matter what, the server would run like a whooped dog until it was rebooted. When I switched to mod_fcgid the server became stable, and always fast all the time. There was much rejoicing. I chose mod_fcgid instead of mod_fastcgi because mod_fastcgi is being maintained as an official fedora repository package and mod_fastcgi isn't. That made mod_fcgid the easiest thing for me from the server deployment and maintenance viewpoint. I don't consider the apache configuration to be difficult to manage. I maintain a separate config file for each virtualhost, and it's just as easy to swap values in those files and issue 'service httpd reload' as it is to switch around your production and head init.d scripts and issue init.d restarts. I haven't experienced any dropped requests using this method when deploying a new revision of the app. From the discussions in this thread it sounds like there could be better benefits using FastCGIExternalServer, but it will probably be a while before I give that route another try. /Mitch Speaking of kill -9... http://www.youtube.com/watch?v=Fow7iUaKrq4 Felix Antonius Wilhelm Ostmann wrote: Perhaps someone can help me with my problem and external FastCGI :-/ i have a fastcgi start/stop script (dont know anymore from which howto), but i cant make fastcgi_server.sh restart he say he stoped and started properly, but after that the socket is broken?!?! i always need to stop, wait 5 seconds and start then :-/ is there another start/stop daemon out there? Matt S Trout schrieb: On Thu, Feb 07, 2008 at 11:46:36AM -0500, Matt Pitts wrote: I just got advise from mst to not use mod_fcgid in production because it doesn't support external fastcgi and this is the way to do HA apps. I wanted to ask some questions and hear some arguments. I know there's some existing traffic on the list about this, but I thought some fresh info would be nice. We're currently running a Cat app under mod_fcgid in production that handles about a million hits a day b/t Cat and static files. Why did we chose mod_fcgid? Well, I tried playing around with mod_fastcgi for awhile and had problems getting the config straight - admittedly due to a lack of knowledge on my part. Then I read some tidbits about mod_fcgid being better, so I tried it out and it just worked and has been just working ever since. Why is it so much better to have fastcgi as an external process? Is it because this is the only way to realistically to PAR-based deployments? What's wrong with having mod_fcgid do its process management. Because then you restart the FastCGI processes when you restart the web server. With external, you can have - webserver - fastcgi for app version N - fastcgi for app version N+1 all managed separately. that means you can update by - start N+1 - change apache config to point to N+1 - apachectl graceful - stop N which allows you to update with zero downtime - without even dropping a single request on the floor. And if something goes wrong, you can perform the process in reverse just as easily. I consider this essential for heavily-used applications since having a 5+ second window of mid-upgrade when the app doesn't respond is a pain in the ass for users. For less heavily used applications I don't care - apache starts the fastcgi handlers for shadowcat.co.uk because it's mostly a news + brochureware type site so a few seconds' downtime every so often really just doesn't matter to us. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Why use external FastCGI apps?
Although I haven't had any experience yet with *external* fastcgi, I'm feeling this approach as well, mainly because it allows me to hang my hat on the starting/stopping/reloading of apache. I'm also trying to treat an Apache vhost like an appliance that I can drop anywhere. I basically have *everything* related to a single vhost organized under a standard structure and I keep it all in Subversion. This way, deploying a site to a different machine is - get vhost appliance from subversion - symlink vhost conf file into apache vhosts.d - sync logs if necessary - apache reload I know my model isn't perfect, but if I use external fastcgi then it adds an easily looked over step - create/symlink some fastcgi init script. The only things that will definitively push the use of external fastcgi are: if I cannot get mod_fcgid to work with PAR files; or if I'm happy with external fastcgi testing/memory usage and can integrate it into my vhost model without too much unhappiness. v/r -matt pitts -Original Message- From: Mitchell Jackson [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 10:58 AM To: The elegant MVC web framework Subject: Re: [Catalyst] Why use external FastCGI apps? I experienced similar behavior with Catalyst when using external FastCGI controlled by init.d under two FC8 boxes. When the app was restarted, it never came back. The processes were still there, but the socket became non-responsive. Issuing another start command would bring up another copy of the app that worked, but the old processes were still running on the system and eventually caused the running live app to come to a crawl. This lead to a daily purge cycle where, in the mornings before users started hitting the system, I would stop the app and then check the process list for any app processes still hanging around and kill them. Generally, only kill -9 would do the trick. On really busy days, I might have to do this purge process later in the afternoon as well. And after a few weeks, no matter what, the server would run like a whooped dog until it was rebooted. When I switched to mod_fcgid the server became stable, and always fast all the time. There was much rejoicing. I chose mod_fcgid instead of mod_fastcgi because mod_fastcgi is being maintained as an official fedora repository package and mod_fastcgi isn't. That made mod_fcgid the easiest thing for me from the server deployment and maintenance viewpoint. I don't consider the apache configuration to be difficult to manage. I maintain a separate config file for each virtualhost, and it's just as easy to swap values in those files and issue 'service httpd reload' as it is to switch around your production and head init.d scripts and issue init.d restarts. I haven't experienced any dropped requests using this method when deploying a new revision of the app. From the discussions in this thread it sounds like there could be better benefits using FastCGIExternalServer, but it will probably be a while before I give that route another try. /Mitch Speaking of kill -9... http://www.youtube.com/watch?v=Fow7iUaKrq4 Felix Antonius Wilhelm Ostmann wrote: Perhaps someone can help me with my problem and external FastCGI :-/ i have a fastcgi start/stop script (dont know anymore from which howto), but i cant make fastcgi_server.sh restart he say he stoped and started properly, but after that the socket is broken?!?! i always need to stop, wait 5 seconds and start then :-/ is there another start/stop daemon out there? Matt S Trout schrieb: On Thu, Feb 07, 2008 at 11:46:36AM -0500, Matt Pitts wrote: I just got advise from mst to not use mod_fcgid in production because it doesn't support external fastcgi and this is the way to do HA apps. I wanted to ask some questions and hear some arguments. I know there's some existing traffic on the list about this, but I thought some fresh info would be nice. We're currently running a Cat app under mod_fcgid in production that handles about a million hits a day b/t Cat and static files. Why did we chose mod_fcgid? Well, I tried playing around with mod_fastcgi for awhile and had problems getting the config straight - admittedly due to a lack of knowledge on my part. Then I read some tidbits about mod_fcgid being better, so I tried it out and it just worked and has been just working ever since. Why is it so much better to have fastcgi as an external process? Is it because this is the only way to realistically to PAR-based deployments? What's wrong with having mod_fcgid do its process management. Because then you restart the FastCGI processes when you restart the web server. With external, you can have - webserver - fastcgi for app version N - fastcgi for app version N+1 all managed separately. that means you can update by - start N+1 - change apache config
Re: [Catalyst] Why use external FastCGI apps?
On Thu, Feb 07, 2008 at 11:46:36AM -0500, Matt Pitts wrote: I just got advise from mst to not use mod_fcgid in production because it doesn't support external fastcgi and this is the way to do HA apps. I wanted to ask some questions and hear some arguments. I know there's some existing traffic on the list about this, but I thought some fresh info would be nice. We're currently running a Cat app under mod_fcgid in production that handles about a million hits a day b/t Cat and static files. Why did we chose mod_fcgid? Well, I tried playing around with mod_fastcgi for awhile and had problems getting the config straight - admittedly due to a lack of knowledge on my part. Then I read some tidbits about mod_fcgid being better, so I tried it out and it just worked and has been just working ever since. Why is it so much better to have fastcgi as an external process? Is it because this is the only way to realistically to PAR-based deployments? What's wrong with having mod_fcgid do its process management. Because then you restart the FastCGI processes when you restart the web server. With external, you can have - webserver - fastcgi for app version N - fastcgi for app version N+1 all managed separately. that means you can update by - start N+1 - change apache config to point to N+1 - apachectl graceful - stop N which allows you to update with zero downtime - without even dropping a single request on the floor. And if something goes wrong, you can perform the process in reverse just as easily. I consider this essential for heavily-used applications since having a 5+ second window of mid-upgrade when the app doesn't respond is a pain in the ass for users. For less heavily used applications I don't care - apache starts the fastcgi handlers for shadowcat.co.uk because it's mostly a news + brochureware type site so a few seconds' downtime every so often really just doesn't matter to us. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
Perhaps someone can help me with my problem and external FastCGI :-/ i have a fastcgi start/stop script (dont know anymore from which howto), but i cant make fastcgi_server.sh restart he say he stoped and started properly, but after that the socket is broken?!?! i always need to stop, wait 5 seconds and start then :-/ is there another start/stop daemon out there? Matt S Trout schrieb: On Thu, Feb 07, 2008 at 11:46:36AM -0500, Matt Pitts wrote: I just got advise from mst to not use mod_fcgid in production because it doesn't support external fastcgi and this is the way to do HA apps. I wanted to ask some questions and hear some arguments. I know there's some existing traffic on the list about this, but I thought some fresh info would be nice. We're currently running a Cat app under mod_fcgid in production that handles about a million hits a day b/t Cat and static files. Why did we chose mod_fcgid? Well, I tried playing around with mod_fastcgi for awhile and had problems getting the config straight - admittedly due to a lack of knowledge on my part. Then I read some tidbits about mod_fcgid being better, so I tried it out and it just worked and has been just working ever since. Why is it so much better to have fastcgi as an external process? Is it because this is the only way to realistically to PAR-based deployments? What's wrong with having mod_fcgid do its process management. Because then you restart the FastCGI processes when you restart the web server. With external, you can have - webserver - fastcgi for app version N - fastcgi for app version N+1 all managed separately. that means you can update by - start N+1 - change apache config to point to N+1 - apachectl graceful - stop N which allows you to update with zero downtime - without even dropping a single request on the floor. And if something goes wrong, you can perform the process in reverse just as easily. I consider this essential for heavily-used applications since having a 5+ second window of mid-upgrade when the app doesn't respond is a pain in the ass for users. For less heavily used applications I don't care - apache starts the fastcgi handlers for shadowcat.co.uk because it's mostly a news + brochureware type site so a few seconds' downtime every so often really just doesn't matter to us. -- Mit freundlichen Grüßen Felix Antonius Wilhelm Ostmann -- Websuche Search Technology GmbH Co. KG Martinistraße 3 - D-49080 Osnabrück - Germany Tel.: +49 541 40666-0 - Fax:+49 541 40666-22 Email: [EMAIL PROTECTED] - Website: www.websuche.de -- AG Osnabrück - HRA 200252 - Ust-Ident: DE814737310 Komplementärin: Websuche Search Technology Verwaltungs GmbH - AG Osnabrück - HRB 200359 Geschäftsführer: Diplom Kaufmann Martin Steinkamp -- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Why use external FastCGI apps?
Thanks for explanation, this makes a lot of sense to me. Does anyone know if Apache's mpm_worker is compatible with mod_fastcgi and external fastcgi? Is there any real benefit of threads in this scenario? v/r -matt pitts -Original Message- From: Yuval Kogman [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 12:23 PM To: The elegant MVC web framework Subject: Re: [Catalyst] Why use external FastCGI apps? On Thu, Feb 07, 2008 at 11:46:36 -0500, Matt Pitts wrote: Why is it so much better to have fastcgi as an external process? In my experience it has been much simpler to set up the fcgi processes as separate entities, simply because the heap of config sh*t is less monolithic. Conceptually it's a bit more like the webserver is a reverse proxy for several application specific web servers, and it doesn't try to meddle with their business in any way. This means you can restart apps independantly, easily manipulate the environment (which perl runs it, etc), without bothering to do it in a roundabout way by specifying what you want in the http server's silly configuration language. This simplicity has paid off for me simply in configuration time - there is far less black magic, figuring out who is calling who, etc. It's easy to figure out where the problem lies, and how to go about fixing it quickly. When the webserver is also the process manager things can get nasty. What's wrong with having mod_fcgid do its process management. If I'm not mistaken good process management is one of the design goals of this project. Finally, it's also a bit tricky to figure out when/where the actual listen/fork calls are made. With a standalone fcgi server the perl side is in control of the forking, so you can be 100% sure you can benefit from page copy on write (less memory). I don't know about mod_fcgid but both apache and lighttpd's builtin fastcgi + process management from the webserver couldn't support this and I doubt they ever will be able to, the fork just has to happen too early. Why did we chose mod_fcgid? Well, I tried playing around with mod_fastcgi for awhile and had problems getting the config straight - admittedly due to a lack of knowledge on my part. Then I read some tidbits about mod_fcgid being better, so I tried it out and it just worked and has been just working ever since. I had the same Just Works™ behavior with sockets, which is why I switched from apache/lighttpd in the managed setup to standalone. I'm one of those folks who hates writing/managing his own daemon management scripts, so if something is going to do it for me and it works then I'm happy to use it. you can easily cargo cult an /init.d for this, the catalyst fastcgi script will do the actual process management on it's own (including writing a PID file, etc). Look at its command line options. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
Den Thursday 07 February 2008 19:05:48 skrev Matt Pitts: Thanks for explanation, this makes a lot of sense to me. Does anyone know if Apache's mpm_worker is compatible with mod_fastcgi and external fastcgi? Is there any real benefit of threads in this scenario? That's how I've installed it. -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why use external FastCGI apps?
On Thu, Feb 07, 2008 at 13:05:48 -0500, Matt Pitts wrote: Thanks for explanation, this makes a lot of sense to me. Does anyone know if Apache's mpm_worker is compatible with mod_fastcgi and external fastcgi? Is there any real benefit of threads in this scenario? threaded mpm for apache is orthogonal to this, it only applies to mod_perl itself. Within your external or managed fastcgi you can use threads or forks or whatever, there is no relation between them anymore, except through the named socket (the user running the fastcgi must be able to write to the dir making the socket, and the user running the webserver must be able to read the socket). In general threads for perl are... not that hot. The only plausible reason I can think of for using threads out of choice is... uh. can't think of any. =P Since inter thread data sharing in perl is kinda clunky (you need to recursively share an entire data structure, you can't just pass references through some queue) they offer no real advantage over traditional IPC with separate processes (they do consume more memory as a general rule though). -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpMvsvob6QAX.pgp Description: PGP signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
