Well, I'm sure no expert, but that doesn't stop me from having opinions. The reasons I stopped using mod_perl are: safer when perl encounters errors, easier for learning, easier for development, better error messages when restarting production applications, and the ability to have each application run as a different system user.
Perhaps the most compelling reason that I stopped using mod_perl is because with both perl and the web server combined in one executable, a problem with perl can cause not only the whole website to go down, but also all the other websites handled by that same webserver to go down as well. Second, setting up staging servers so you can develop without touching your production site is easier using fastcgi. Even having one staging server with mod_perl is difficult. Will you run two whole apaches simultaneously? What if you want to have more than one staging server? Adding more staging servers gets ridiculous fast. (BTW, I know the Catalyst Book says that you're supposed to use the myapp_server.pl for development, but I want to have SSL turned on all the time.) With fastcgi, I literally had dozens of different applications running at once, and they can all crash and burn and the webserver keeps running. In fact, that's how I learned to use Catalyst. For every tutorial I found, I made its own fastcgi process, and then I set up the web server to know about each one. http://myhost.com/alpha was the authorization tutorial, /beta was the CRUD totorial, etc. I could look at and play with any or all of them running at once; it made learning from examples much easier. In addition to making it easier to learn and to development, in the production environment fastcgi has significant advantages as relates to error messages, restarting, and security: I can have two levels of error messages: one is the replacement for the "Internal Server Error" that results from a problem with perl running--the same error you arleady have, for example if your database server crashes, generated by the perl application. But with fastcgi I have another, separate error page that is a nice-looking static page served by the web server when the fasccgi server is not there. So during the time when I am restarting my fastcgi application, visitors see that nice static page rather than getting a browser error message, which is what happens when you restart a server with mod_perl. And as your application(s) grow in size (and number), restarting them takes longer and longer, so that feature becomes more important. Finally, a wonderful benefit of using fastcgi is that each one of my fastcgi applications runs as a separate user, and none of those fastcgi users is the user that the web server runs as. I sleep that much better at night knowing that the web server cannot read the files that have database passwords in them, and so on. Anyway, that's my conclusion after doing things both ways. My current setup is similar to yours: FreeBSD, lighttpd, Catalyst, and PostgreSQL. Adam PS, I'm curious why you're using mysql. Is there a way in which its better than Postgres? On Fri, Jan 29, 2010 at 04:35:10PM +0530, Amit Jha wrote: > Does anyone have any advice on what will the best option mod_perl or > FastCGI or something else. if I have the following > development/production environment for my web application which is a > search engine. > 1. Linux(RHEL5) > 2. Apache 2.2.x > 3. Perl 5.10 > 4. mod_perl 2.0.x > 5. mysql 5.1.x > 6. Catalyst 5.8.x > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
