Yet another sticky/persistent sessions question
dormando
dormando at rydia.net
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
sticky)
gearman disconnects remote workers from clients in several ways.
etc.
I just can't find good reasons for sticky sessions anymore :) It's just
not an even method of scaling.
-Dormando
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 (http://www.danga.com/perlbal/)
>>> 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