Try my new hosted Linode memcached service (BETA)
I did it, I'm opening it, for you to see and test. Well, it took me one week but hey, that was fun to hack into memcached. So, I'm opening a service for Linode users (Dallas data center only for now but more to come !) that lets you share a memcached server.
The idea is kind of an experiment : you share _one_ instance. I don't provide you with fixed and different memcached servers, but you read it correctly : only one. This one is having a 200MB bucket for now but will be upgraded if needed.
How it works: you connect your memcache client to the linode which is running the memcached and I let you in if you registered to the beta. You can use the 200MB bucket as you wich, provided that the maximum expire (TTL) is set to 30 minutes (1800 seconds). Don't ask more, it won't work :)
Well, for the security, you'll probably be happy to know that you can't read/delete/modify keys that are not yours.
You can see this service as a super bursting and free (for now) super service !
In the future, if it works, I plan to make it a paid service but surprise, I would charge only 1 or 2 dollars/month. This way, you can temporary burst a 200MB (more coming !) memcached server for nearly free.
Hope you enjoy it and I'm opened to any suggestion for improvements. To participate to the beta, please visit this webpage which will explain you what you can/can't do , and the way to get it.
http://www.henri.pro/2010/09/25/memcached-shared-instance-beta/
Have a nice week end everyone ! (As usual I'm on #startups my nickname is henri if you want to chit chat)
26 comments
[ 3.1 ms ] story [ 68.3 ms ] threadedit- Just realized you have to being using Linode as well. Now I question this too. I thought this was going to be Memcached as a service.
Hope I could answer your question..
The reason I was slightly interested is because Windows Azure right now doesn't have good support for any sort of distributed cache system. So we've been shopping around.
Memcache will only make sense if it is hosted in the private LAN.
I think the point is that he's only offering it to Linode users in the Dallas data center, which is where his service is located. Therefore the latency will be in the sub 1ms range, comparable to a private LAN. There may be other issues with this approach, but latency isn't one of them, at least in this implementation.
If this trial works, I can relatively say that we won't be talking about 200MB, but GB of "burstable" cache. And you won't get it for free on Linode.
Also, this is an experiment.
One step even further would be, people can spin up on-demand instances of whichever NoSQL server they need - Cassandra, Voldemort, Redis, Riak... you name it.
edit: just to be clear, I'm not offering one instance of memcached per person. It's only one instance for all.
To stick it on the other side of a wire is defeating the purpose, that will in a great many cases increase the time of the request beyond what it would have taken to re-create the original request.
Not to rain on your parade, but I think this is less than useful for production.
Regarding the production, right now it's not intented to replace a real dedicated memcached server.
We don't use Linode, but we do use memcached to store 'partials', and for now I'm skeptical about running that memcached on the other side of a wire, latency tends to fluctuate quite a bit in a busy DC, so you may have to run your test over an extended period of time to get good data.
It helps if your machine is equipped with two ethernet interfaces, one for 'local' traffic and one that is facing the outside world.
When compared to heavy processing on large database queries, memcached -- even with a few extra ms of latency -- can still be a major performance win.
Although this largely depends on the applications you're making. I've been working with GIS applications lately, where a large distributed cache (most memcached clients automatically support sharding) is about the best you can do without a large hardware budget.
In its current form, it's binary only (because we do vertical multi-tenancy there and have no control over multiple applications being on the same instance). It'd be pretty easy to make an IP address based ACL mode for the thing and then you could run binary or ascii just as easily.
Advantages:
* Key containment (e.g. you can do flush_all) * You don't have to hack up your own memcached server * Binary protocol is a bit easier on the server with things like large multi-gets because they don't cause so much request swell
We've also got some basic management stuff for creating and manipulating instances (independently of auth, since we let SASL deal with that).
Disadvantages:
* You'd have to hack in your IP addr -> bucket mapping * If you want TTL limits, you'd need to hack that in, too
Of course, I imagine both are quite easy and would be welcome contributions to the project. :)
Let me know if you're interested and need any help.