Re: Session and Multi Server Architecture
| From: | Per Jessen | Date: | Tue, 12 Feb 2008 07:55:33 +0000 |
| Subject: | Re: Session and Multi Server Architecture | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-269148@lists.php.net to get a copy of this message | ||
Stut wrote:
> Per Jessen wrote:
>> mike wrote:
>>
>>>> Check out persistency in LVS for instance:
>>>>
>>>> http://www.linuxvirtualserver.org/docs/persistence.html
>>> i know persistence handling is an option in LVS, but i haven't seen
>>> the need to use it. i use LVS right now without even bothering with
>>> any of that.
>>
>> Because you've chosen another option - memcached presumably - which
>> is more expensive over all. (IMHO).
>
> Based on what? I'm currently looking at replacing a file-based cache
> with memcached and I'm interested in all justified opinions.
You might not have much use for mine then :-)
If I compare plain session-persistency (session being a client to server
relationship, not $_SESSION) with memcacheds copying objects around
across many machines, common sense tells me that the latter will use a
lot more resources. Both on the network and on each machine.
With memcached, and 1000 clients for a cluster of 50 machines, each
using up 1Mb of $_SESSION space, that is 1000Mb per machine, 50Gb in
total.
With session-persistency, you have 50 machines with 1000/50 clients
each, making 20Mb per machine. And virtually no session-related
inter-machine network traffic. And your machines are not busy with
keeping 980 objects needlessly up-to-date.
Of course, processing power, network capacity and memory are all very
cheap these days, so it's easy to put on the Microsoft hat and be
wasteful.
>> On the next request, LVS will know not to try that server, and the
>> user will move to another one. Obviously the session-context will
>> die, but is that really a big deal? How often does one of your
>> servers die? Sure, if you've got 10,000 in a cluster, you'll have
>> fans and harddisks pop every so often, but I have my doubts about
>> memcached scaling to that level (please correct me if I'm wrong here,
>> I have _no_ experience with memcached).
>
> Facebook. Digg. LiveJournal. That enough scalability proof for ya? If
> not there are plenty more where those came from.
It wasn't really the scalability I was interested in here, but I'd be
interested to hear some numbers if you have any.
My point with the 10,000 machines was - with that many components, even
the 100,000 hours MTBF of a regular harddisk will mean one will break
every ten hours (statistically speaking). Add fan- and other failures
to that, and you'll have sessions dying quite frequently. Which _could_
be a significant problem, and maybe enough to make you want to use
memcached for object replication. (there might also be a restriction in
the number of concurrent clients handled by LVS session persistency).
However, with a much smaller cluster, say 50 or 100 machines, hardware
failures will be a lot less frequent, and having the odd session die
once a week might not be a problem. Which is why I think LVS session
persistency is perfectly fine.
/Per Jessen, Zürich