<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Let me tell you that I am going to deploy 3-tire architecture and
inbuilt application load balancer for my production environment. And In
future I may have h/w load balancer as well. So Its clear thal I am looking at
very fast and stable environment to deliver my content. So Please help me to identify the best better
option.<br><br><div>Amit<br></div><div><strong><em><font face="Times New Roman" size="5">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font></em></strong></div><br><br>--- On <b>Sat, 30/1/10, Adam Mackler <i>&lt;nabble@mackler.org&gt;</i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Adam Mackler &lt;nabble@mackler.org&gt;<br>Subject: Re: [Catalyst] Using Catalyst with mod_per or FastCGI on heavy traffic web application<br>To: shanu_040@yahoo.co.in, "The elegant MVC web framework" &lt;catalyst@lists.scsys.co.uk&gt;<br>Date: Saturday, 30 January, 2010, 6:02 AM<br><br><div class="plainMail">Well, I'm sure no expert, but that doesn't stop me from having opinions.<br><br>The reasons I stopped using mod_perl are: safer when perl encounters<br>errors, easier for learning, easier for development, better error<br>messages when restarting
 production applications, and the ability to<br>have each application run as a different system user.<br><br>Perhaps the most compelling reason that I stopped using mod_perl is<br>because with both perl and the web server combined in one executable,<br>a problem with perl can cause not only the whole website to go down,<br>but also all the other websites handled by that same webserver to go<br>down as well.<br><br>Second, setting up staging servers so you can develop without touching<br>your production site is easier using fastcgi.&nbsp; Even having one staging<br>server with mod_perl is difficult.&nbsp; Will you run two whole apaches<br>simultaneously?&nbsp; What if you want to have more than one staging<br>server?&nbsp; Adding more staging servers gets ridiculous fast.<br><br>(BTW, I know the Catalyst Book says that you're supposed to use the<br>myapp_server.pl for development, but I want to have SSL turned on all<br>the time.)<br><br>With fastcgi, I
 literally had dozens of different applications running<br>at once, and they can all crash and burn and the webserver keeps<br>running.&nbsp; In fact, that's how I learned to use Catalyst.&nbsp; For every<br>tutorial I found, I made its own fastcgi process, and then I set up<br>the web server to know about each one.&nbsp; <a href="http://myhost.com/alpha" target="_blank">http://myhost.com/alpha</a> was<br>the authorization tutorial, /beta was the CRUD totorial, etc.&nbsp; I could<br>look at and play with any or all of them running at once; it made<br>learning from examples much easier.<br><br>In addition to making it easier to learn and to development, in the<br>production environment fastcgi has significant advantages as relates<br>to error messages, restarting, and security: I can have two levels of<br>error messages: one is the replacement for the "Internal Server Error"<br>that results from a problem with perl running--the same error you<br>arleady
 have, for example if your database server crashes, generated<br>by the perl application.&nbsp; But with fastcgi I have another, separate<br>error page that is a nice-looking static page served by the web server<br>when the fasccgi server is not there.&nbsp; So during the time when I am<br>restarting my fastcgi application, visitors see that nice static page<br>rather than getting a browser error message, which is what happens<br>when you restart a server with mod_perl.&nbsp; And as your application(s)<br>grow in size (and number), restarting them takes longer and longer, so<br>that feature becomes more important.<br><br>Finally, a wonderful benefit of using fastcgi is that each one of my<br>fastcgi applications runs as a separate user, and none of those<br>fastcgi users is the user that the web server runs as.&nbsp; I sleep that<br>much better at night knowing that the web server cannot read the files<br>that have database passwords in them, and so
 on.<br><br>Anyway, that's my conclusion after doing things both ways.&nbsp; My current<br>setup is similar to yours:&nbsp; FreeBSD, lighttpd, Catalyst, and<br>PostgreSQL.<br><br>Adam<br><br>PS, I'm curious why you're using mysql.&nbsp; Is there a way in which its<br>better than Postgres?<br><br>On Fri, Jan 29, 2010 at 04:35:10PM +0530, Amit Jha wrote:<br>&gt; Does anyone have any advice on what will the best option mod_perl or<br>&gt; FastCGI or something else. if I have the following<br>&gt; development/production environment for my web application which is a<br>&gt; search engine.<br>&gt; 1. Linux(RHEL5)<br>&gt; 2. Apache 2.2.x<br>&gt; 3. Perl 5.10<br>&gt; 4. mod_perl 2.0.x<br>&gt; 5. mysql 5.1.x<br>&gt; 6. Catalyst 5.8.x<br>&gt; _______________________________________________<br>&gt; List: <a ymailto="mailto:Catalyst@lists.scsys.co.uk" href="/mc/compose?to=Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>&gt; Listinfo: <a
 href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>&gt; Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>&gt; Dev site: <a href="http://dev.catalyst.perl.org/" target="_blank">http://dev.catalyst.perl.org/</a><br><br></div></blockquote></td></tr></table><br>



      <!--1--><hr size=1></hr> 
The INTERNET now has a personality. YOURS! <a href="http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/" target="_blank">See your Yahoo! Homepage</a>.