On 2/12/08, Per Jessen <per@xxxxxxxxxxxx> 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 those cases where your > object is on your local memcached). > > I've very likely overlooked something or other, but overall memcached > seems to me to be unnecessarily complicated when the same problem can > be solved with session persistency (even if you have to accept a > slightly uneven load at times). As of pecl memcache 3.0.0 they have client-side support to push the data to more than one server (neat idea) - so you'd have a backup in case the primary went down without threat of a full cache stampede... 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 session data is a crappy user experience :)) I would suggest using MySQL (unless traffic is huge and needs lightweight memcached instead) for session storage. It alleviates the need for any sort of persistence and is easily transferrable to any server. I use it on all my webapps - single server or multi-server. memcached is a bit more unique, if you don't own the server you might have an issue getting support for it, but a PHP+MySQL combination is pretty standard, and typically the application already has a MySQL connection needed, so it's not really adding any additional connection overhead (if your connection stuff is handled properly and doesn't duplicate connections) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
