With open-source software you basically get the features that programmers over time have wanted, and it was good enough to be included for others. One of the cool things about open-source is that if the product is mostly what you want but misses a key feature that you want (but others dont seem to), you can normally find someone familiar with the code who would be willing to work on your feature for some dollars.
If you are willing to spend $40k on a server, put down a bounty of a few hundred bucks and see if anyone will pick it up. On Wed, Sep 10, 2008 at 10:04 AM, PlumbersStock.com < [EMAIL PROTECTED]> wrote: > > 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. > -- "Be excellent to each other"
