On 2/13/08, Per Jessen <[EMAIL PROTECTED]> wrote:
> Ah, but each server will only have what it needs for its clients. So if
> you've got say 2000 clients spread over 10 servers, each server will
> have the data relevant for its 200 clients. And there is no need for
> network access everytime you
mike wrote:
> On 2/12/08, Per Jessen <[EMAIL PROTECTED]> wrote:
>
>> Cache layers are cheap - it's a known science after all. The key
>> thing
>> (AFAICT) about memcached is that is _distributed_. You need this
>> when you don't have session persistency (session being the
>> client-to-server re
On 2/12/08, Per Jessen <[EMAIL PROTECTED]> wrote:
> Cache layers are cheap - it's a known science after all. The key thing
> (AFAICT) about memcached is that is _distributed_. You need this when
> you don't have session persistency (session being the client-to-server
> relationship).
correct. l
mike wrote:
> To me it isn't a memcached vs. session persistency debate. memcached
> to me is a cache layer for anything - if I wanted to use it for
> sessions, it's an added bonus (I'd probably make sure to use 3.0.0+ so
> I could ensure the data is in more than one server, losing people's
> sess
On 2/12/08, Per Jessen <[EMAIL PROTECTED]> wrote:
> My mistake - I though I'd understood that memcached would replicate
> objects across the servers, but that's clearly wrong.
> If I've got it right, virtually every access to a cached object will
> require network traffic? (the exception being tho
Stut wrote:
There's no question of locking users to particular machines, nor of
uneven distribution. LVS will distribute evenly or according to
weights.
>>> Indeed, but you must see that making the decision of which server to
>>> use per request will result in a more even distribut
6 matches
Mail list logo
