Yet another sticky/persistent sessions question

dormando dormando at
Thu Apr 24 17:41:31 UTC 2008

A philosophy on perlbal (and the danga stack in general) is that sticky 
sessions are entirely wrong. A client request _must_ go where there are 
resources free, not where it feels comfortable going.

This is reflected in the most of the danga stack:

perlbal disconnects requests from backends, can send anywhere while 
making use of persistent connections on both ends.
memcached distributes caches to any number of machines...
mogilefs puts storage into a cloud via lookup service (that's also not 
gearman disconnects remote workers from clients in several ways.

I just can't find good reasons for sticky sessions anymore :) It's just 
not an even method of scaling.

Mathew Snyder wrote:
> That's what I was thinking.  Thanks for the response.
> I've been asking if distributed sessions would be viable and have 
> received semi-positive responses but they definitely insist on sticky 
> sessions.
> Mathew
> Todd Lipcon wrote:
>> Hi Mathew,
>> Perlbal does not support sticky sessions in its stock configuration. 
>> The "persistent client connections" mentioned on the web is simple 
>> HTTP Keepalive support.
>> There may be a plugin out there that can make perlbal do traditional 
>> "sticky sessions", but I haven't seen it if so.
>> Most people opt to distribute their session store so stickiness is not 
>> necessary.
>> -Todd
>> On Thu, 24 Apr 2008, Mathew Snyder wrote:
>>> I'm looking at the perlbal webpage ( 
>>> and I see that it lists "Persistent client connections 
>>> (configurable)" as one of its capabilities as a reverse proxy.  I'm 
>>> still slightly confused because I've not found anything online that 
>>> provides definitive confirmation that Perlbal can handle persistent 
>>> sessions.  Or, am misinterpreting this and incorrectly calling 
>>> "persistent client connections" sticky sessions.
>>> We're looking to update our load balancing configuration and if we 
>>> are able to get the one function from Perlbal we will be able to 
>>> seriously consider its use.  Otherwise we'll have to go a different 
>>> route.
>>> Thanks for the help,
>>> Mathew

More information about the perlbal mailing list