<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The states output is from only one perlbal instance, so the real numbers are basically double that. Here is my basic config:
<br><br>CREATE SERVICE feeds<br>&nbsp; SET role&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = reverse_proxy<br>&nbsp; SET pool&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = feedspool
<br>&nbsp; SET persist_client&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = on<br>&nbsp; SET persist_backend&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = on<br>&nbsp; SET verify_backend&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = on<br>&nbsp; SET connect_ahead&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = 50<br>&nbsp; SET enable_error_retries&nbsp; = on<br>&nbsp; SET backend_persist_cache = 20<br>
&nbsp; SET balance_method&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = random
<br>ENABLE feeds<br><br>I have my backends configured to handle 275 threads each (which if they actually did serve that many at once would explode) because I haven&#39;t really optimized that number for &quot;the perlbal way&quot;. Perlbal has yet to actually connect that many to a backend by a long shot. Does it make sense for me to go with a large connect_ahead and/or backend_persist_cache? I&#39;m still a bit unclear on what specifically each does? Or should I stick with the numbers I have? Should they be the same number? I figured that setting it high would just waste more cpu cycles if Perlbal is constantly iterating through a bunch of bored connections deciding whether to keep them connected or not.
</blockquote></div><br>Briefly, connect_ahead instructs Perlbal to pre-load connection creation and backend verification.&nbsp; It starts the process even if it doesn&#39;t have any requests, and it keeps the process going so you have this many bored backends (well, it tries).&nbsp; The backend_persist_cache is how many bored backends can sit around before being killed off.
<br><br>Your connect_ahead is definitely too high IMO.&nbsp; Unless you&#39;re expecting huge spikes of traffic where it&#39;s vitally important for you to shave off the time it takes Perlbal to handshake and verify a new backend connection, that many pre-started connections doesn&#39;t really help anything and just serves to take up cycles.&nbsp; Unless you really think you need to save that startup time, this can be turned off completely or set to a low value of 3-5.
<br><br>The backend_persist_cache is good to keep at some level in order to allow persistent backend connections to survive short lulls in traffic. &nbsp; Your 20 seems a reasonable number, I&#39;ve used lower in the past, but it doesn&#39;t really matter that much.&nbsp; This doesn&#39;t create extra work for Perlbal, it just defines how much work it is allowed to get rid of, banking on not needing those surplussed backend connections right away.
<br><br>Neither of these tweaks will really change the general performance values of Perlbal though.&nbsp; If you&#39;re running XS headers and not doing anything special with custom plugins, I don&#39;t think there&#39;s too much more you can do to speed it up.&nbsp; Perhaps if you are serving static files by your backends and not by Perlbal, you could consider moving them to the Perlbal machines.&nbsp; It takes less CPU to do a local sendfile than a reverse proxy operation.&nbsp; (But then, I seem to recall your states output indicated you&#39;re already doing local file serving on the Perlbals...)
<br><br><br>-- <br>Mark Smith / xb95<br><a href="mailto:smitty@gmail.com">smitty@gmail.com</a>