Usually store maybe between 1 and 4GB of data but the backend the data comes from is unreasonably slow. Nothing we can do about it. We've bought a new $40,000 server for it this year just to make it bearable.
On Sep 9, 8:00 pm, Joseph Engo <[EMAIL PROTECTED]> wrote: > I played around with a version of memcached that supported replication > and it didn't work very well. Normal get and set were ok, but > increments / decrement got all messed up during fail overs. > > Just curious, how much data are you storing in your memcache ? > > On Sep 9, 2008, at 6:38 PM, PlumbersStock.com wrote: > > > > > That sounds more complex than simply dumping a copy of what's in > > memory to disk and restoring it five minutes later when the system is > > restarted. If I understand correctly, memcached doesn't offer > > replication so I'd have to somehow make it do so myself - right? > > > On Sep 9, 7:24 pm, Joseph Engo <[EMAIL PROTECTED]> wrote: > >> You could have a secondary memcache pool that you warm up during > >> maintenance periods, then switch over temporarily (using a load > >> balancer). > > >> On Sep 9, 2008, at 6:04 PM, PlumbersStock.com wrote: > > >>> Is there any technical reason that memcache shouldn't dump it's db > >>> to > >>> disk when shutdown and restore it when started again? If save/ > >>> restore > >>> were options I could rewrite my start/stop scripts to do it - those > >>> who didn't want it wouldn't have to have it. > > >>> This would be a handy option for me as it takes me hours to rebuild > >>> after a system shutdown. My backend system is proprietary and slow > >>> which is the main reason for caching everything in memcached in the > >>> first place. I was caching everything in a MySQL db before but > >>> memcached is quite a bit faster and less intensive on my server.
