<br><br><div class="gmail_quote">On Fri, Jan 29, 2010 at 10:59 PM, Adam Mackler <span dir="ltr"><<a href="mailto:nabble@mackler.org">nabble@mackler.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div><br>
But with mod_perl, when you're restarting your application, you're<br>
starting the whole web server, so during that time...which can be<br>
longer than you expect for a number of reasons...people attempting to<br>
reach your site will get browser errors saying your site is down or<br>
unreachable. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
But with fastcgi, the web server keeps running and can serve a static<br>
error page while the fastcgi server is not available. And with no<br>
perl in the mix, restarting the web server itself takes less time and<br>
can be done more gracefully.<br></blockquote><div><br></div><div>That makes no sense. If fastcgi processes are down, then, well they are down. If all your mod_perl servers are down, they are, well, down.</div><div><br></div>
<div>Maybe you are assuming the Apache that is running mod_perl also serves static content? Or that there's only one web server? Or there's no load balancer? Or it's not run with a reverse proxy as is the standard approach?</div>
<div><br></div><div>We found that restarting with FastCGI took longer. Maybe that was because each process has to compile the app (instead of compile and fork to many processes?). Is that true? I can't remember.</div>
<div><br></div><div><br></div><div><br></div></div><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>