<div>Ruslan,</div><div> </div><div>I agree with your recommendation in general for most installations, especially ones larger than ours.  I don't think increasing the KeepAliveTimeout is necessary anymore now that I fixed the swapping issue, because the initial page load does not take a long time anymore.  However, for our environment I know that there will never be more than 5 people accessing the site at once, so we will never run into the scenario you were giving as an example.  The reason I left the KeepAliveTimeout at 60 was because I'd like to have it as fast as possible once a user starts doing something, and I think a user could look at a ticket for more than 15 seconds (the default KeepAliveTimeout in my apache configuration) and then continue on, but it's not as likely they would take longer than 60 seconds in between clicks.  For our environment it would be fine to have 5 apache processes dedicated for 5 users at once.  </div>
<div> </div><div>Thanks for the information on the lightweight front-end, it looks like it would help a lot, although I think it might be overkill for our relatively small installation.</div><div> </div><div>-Nate<br><br>
</div><div class="gmail_quote">On Sat, Jun 2, 2012 at 6:00 PM, Ruslan Zakirov <span dir="ltr"><<a href="mailto:ruz@bestpractical.com" target="_blank">ruz@bestpractical.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div class="im">
It shouldn't be necessary if you know how to fit things in.<br>
<br>
You don't want KeepAliveTimeout to be very high. Keep alive at 60<br>
seconds means that user when touched apache process holds it from<br>
serving other users for 60 seconds even if he doesn't do anything. 10<br>
users hit the server within a minute - you need 11 apache processes to<br>
serve next user. Your deployment is not configured for such values.<br>
<br>
For big keep alive values you need two step processing with light<br>
frontend and heavy backend. Frontend keep connections open and can<br>
hold many of them with low footprint. For example take a look at the<br>
following blog post:<br>
<a href="http://blog.webfaction.com/a-little-holiday-present" target="_blank">http://blog.webfaction.com/a-little-holiday-present</a>, especially memory<br>
footprint chart.<br>
<br>
As the backend you either use FCGI server running RT, your current<br>
apache setup or something else.<br>
<br>
Take a look at the following extension:<br>
<br>
<a href="http://search.cpan.org/~ruz/RT-Extension-Nginx-0.02/lib/RT/Extension/Nginx.pm#FEATURES" target="_blank">http://search.cpan.org/~ruz/RT-Extension-Nginx-0.02/lib/RT/Extension/Nginx.pm#FEATURES</a><br>
<br>
It generates config for nginx where a few features of the server and<br>
knowledge of RT are used to lower memory footprint, increase<br>
concurrency, lower page load times.<br></div>
<div class="HOEnZb"><div class="h5"><br>
<span class="HOEnZb"><font color="#888888">--<br>
Best regards, Ruslan.<br>
</font></span></div></div></blockquote></div><br>