Thanks for the advice. I dropped my connect_ahead down to 10 and left backend_persist_cache at 20. CPU usage seems to have dropped about 10-20%.<br><br>I don't have perlbal serving any static resources yet. Since only some servers are behind Perlbal, we haven't made any application changes yet to make better use of Perlbal but that is definitely something I'll be checking out. One thing I'm confused about though in regards to the static serving, is the whole Linux::AIO vs IO::AIO thing. Is one better than the other? Or are they actually the same thing? I have IO::AIO installed, but basically being unused so far since Perlbal is not serving any static content.
<br><br><div class="gmail_quote">On Oct 30, 2007 7:42 PM, Mark Smith <<a href="mailto:smitty@gmail.com">smitty@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><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> SET role = reverse_proxy<br> SET pool = feedspool
<br> SET persist_client = on<br> SET persist_backend = on<br> SET verify_backend = on<br> SET connect_ahead = 50<br> SET enable_error_retries = on<br> SET backend_persist_cache = 20<br>
SET balance_method = 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't really optimized that number for "the perlbal way". 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'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></div>Briefly, connect_ahead instructs Perlbal to pre-load connection creation and backend verification. It starts the process even if it doesn't have any requests, and it keeps the process going so you have this many bored backends (well, it tries). 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. Unless you're expecting huge spikes of traffic where it'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't really help anything and just serves to take up cycles. 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. Your 20 seems a reasonable number, I've used lower in the past, but it doesn't really matter that much. This doesn'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. If you're running XS headers and not doing anything special with custom plugins, I don't think there's too much more you can do to speed it up. Perhaps if you are serving static files by your backends and not by Perlbal, you could consider moving them to the Perlbal machines. It takes less CPU to do a local sendfile than a reverse proxy operation. (But then, I seem to recall your states output indicated you're already doing local file serving on the Perlbals...)
<div><div></div><div class="Wj3C7c"><br><br><br>-- <br>Mark Smith / xb95<br><a href="mailto:smitty@gmail.com" target="_blank">smitty@gmail.com</a>
</div></div></blockquote></div><br>