Is this a dynamic application (scripting language + database queries)?<br><br>If so then: Caching, caching and more caching ...<br><br>The page that will be on Slashdot/Digg would ideally be a flat HTML, or something similar (e.g. memcached). This bypasses all the dynamic stuff and you can serve it in 10-20 milliseconds flat per request. Many applications have a dynamic -> static automatic builder of one sort or another ...<br>
<br>The other part is traffic. If you are in a good datacenter, I would not worry too much about it, since you already are connected to a wide pipe. I have been Slashdotted on a few occasions and this is not a concern.  On the other hand, if you are on a residential asymmetric link, your "upload" speed would not be enough.<br>
<br>Syncing 2 web heads is more painful than just one server, and incurs overheads in additional complexity and performance. So avoid it if you can. KISS works best ...<br><br><div class="gmail_quote">On Wed, Feb 17, 2010 at 2:06 PM, Insurance Squared Inc. <span dir="ltr"><<a href="mailto:gcooke@insurancesquared.com">gcooke@insurancesquared.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If we're trying to preplan for getting slashdotted on our webservers, what's the best low tech way to handle that?  I've got two identical webservers I can light up, but don't know how to share traffic, sync, etc.  I suspect some type of clustering is the answer in linux these days, but I don't even know what that really is :).<br>
</blockquote></div>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra<br>
Simplicity is the ultimate sophistication. --   Leonardo da Vinci<br>