<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Loadbalancer for horizontal web scaling: What questions to ask before implementing one.</title>
	<atom:link href="http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/</link>
	<description>Performance and availability matters too...</description>
	<pubDate>Tue, 06 Jan 2009 04:51:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: John Chen</title>
		<link>http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/#comment-868</link>
		<dc:creator>John Chen</dc:creator>
		<pubDate>Wed, 27 Aug 2008 22:34:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/#comment-868</guid>
		<description>Good insights that could save a bit a grief and time.

Cheers!</description>
		<content:encoded><![CDATA[<p>Good insights that could save a bit a grief and time.</p>
<p>Cheers!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Malcolm</title>
		<link>http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/#comment-866</link>
		<dc:creator>Malcolm</dc:creator>
		<pubDate>Wed, 23 Jul 2008 11:54:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/#comment-866</guid>
		<description>Nice post, one of the best I've read. Logical and to the point.
I always stress to customers that if the application is designed to be horizontally scaled then growth and performance is easy to handle.
Chucking in a load balancer without any forward planning is daft.
I also think cookies should be in the application persistence layer not on the load balancer which is a bit of a sticky plaster approach.</description>
		<content:encoded><![CDATA[<p>Nice post, one of the best I&#8217;ve read. Logical and to the point.<br />
I always stress to customers that if the application is designed to be horizontally scaled then growth and performance is easy to handle.<br />
Chucking in a load balancer without any forward planning is daft.<br />
I also think cookies should be in the application persistence layer not on the load balancer which is a bit of a sticky plaster approach.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Israel LHeureux</title>
		<link>http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/#comment-355</link>
		<dc:creator>Israel LHeureux</dc:creator>
		<pubDate>Mon, 24 Sep 2007 18:13:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.royans.net/arch/2007/08/28/loadbalancer-for-horizontal-web-scaling-what-questions-to-ask-before-implementing-one/#comment-355</guid>
		<description>Great post!  Just want to add my $0.02.

For even larger scaling, at least one loadbalancer (&lt;a href="http://www.juniper.net/products_and_services/application_acceleration/data_center_acceleration/dx_application_acceleration/" rel="nofollow"&gt;Juniper DX series&lt;/a&gt;)supports a notion of Active-N, instead of merely active-active or active-standby.

With just Active-Active, you have to keep each SLB's load below 50%, or you won't have failover.  (51%+51%=crash)

ActiveN splits the SLB load among up to 64 individual SLBs, with cascading failover, and it can even work with just one public VIP:Port.  

(Disclaimer: I used to work for the SLB company pre-Juniper acquired them, but the product is still worth checking out.)  

Advanced users might want to investigate other features as well, such as SSL + HTTP compression + Muliplexing back-end connections as well as flexibly rewriting requests or response data (headers and content, both in and out) and on-board caching.   All of these can really improve performance, but different vendors support them differently.  

Always test an SLB in your environment, with your architecture and your data.  And do external, real performance analysis, not simulated "tests" on a LAN.

Cheers!</description>
		<content:encoded><![CDATA[<p>Great post!  Just want to add my $0.02.</p>
<p>For even larger scaling, at least one loadbalancer (<a href="http://www.juniper.net/products_and_services/application_acceleration/data_center_acceleration/dx_application_acceleration/" rel="nofollow">Juniper DX series</a>)supports a notion of Active-N, instead of merely active-active or active-standby.</p>
<p>With just Active-Active, you have to keep each SLB&#8217;s load below 50%, or you won&#8217;t have failover.  (51%+51%=crash)</p>
<p>ActiveN splits the SLB load among up to 64 individual SLBs, with cascading failover, and it can even work with just one public VIP:Port.  </p>
<p>(Disclaimer: I used to work for the SLB company pre-Juniper acquired them, but the product is still worth checking out.)  </p>
<p>Advanced users might want to investigate other features as well, such as SSL + HTTP compression + Muliplexing back-end connections as well as flexibly rewriting requests or response data (headers and content, both in and out) and on-board caching.   All of these can really improve performance, but different vendors support them differently.  </p>
<p>Always test an SLB in your environment, with your architecture and your data.  And do external, real performance analysis, not simulated &#8220;tests&#8221; on a LAN.</p>
<p>Cheers!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
