MemCachier Blog
Announcements, New Features, and How Tos
The AWS infrastructure that MemCachier uses for direct sign-up and Heroku customers evolves over time. Amazon releases new EC2 instance types and new network infrastructure features on a regular basis. In order to exploit these new features, MemCachier occasionally needs to migrate caches to new infrastructure. We are planning to migrate all of our clusters to new AWS infrastructure over the course of the next few weeks, starting with development caches and production caches in less-used AWS regions next week. There is likely to be some limited impact on cache performance during the migration process, particularly as we retire existing EC2 instances in favor of new ones.
We are happy to announce some wide-ranging improvements to our status page. While it looks the same on the surface, it has been rewritten from scratch and is now much more tightly integrated with our monitoring infrastructure. For our customers, this has three main consequences.
We have recently added some additional features to MemCachier. In brief, you can now have multiple sets of credentials for a cache, can rotate credentials, and can restrict some capabilities on a per-credential basis. These features are all controlled from the Credentials panel of the MemCachier dashboard for your cache:
We are happy to announce a new feature for our Heroku customers. In the past we have had several requests from customer who wanted to know why their caches had been flushed. To help our clients find out how a flush command came about we now push a log message to the Heroku log whenever a cache is flushed.
We’re happy to announce the general availability of a new feature on MemCachier, the ability to connect to our servers using the memcache ASCII protocol! Our official documentation covers it here.
We are happy to announce a new design for the analytics dashboard and the ability to move your cache from one cluster to another in emergencies.
Over the last couple days the US-East-C1 cluster experienced some performance issues, the worst of which occurred on September 30th between 8:36am and 8:44am (PST), when latencies were bad enough that several customers apps were severely affected. We’re very sorry to all affected customers and want to explain what happened and what we’re doing to prevent such incidents in the future.
Recently we diagnosed an issue for several of our customers who were
using the python Django web-framework. They were all experiencing
performance issues and a reasonable amount of broken connections to
our servers. The issue was that by default Django uses a new
connection to memcached for each request. This is terrible for
performance in general, paying the cost of an extra round-trip to
setup the TCP connection, but is far worse with cloud-services like
MemCachier that have an security layer and require new connections to
be authenticated. A new connection to a MemCachier server takes at
least 3 round-trips, which increases the time to execute a single
get request by 4x.
UPDATE (Jan, 2016): As of Ubuntu 15.10, libmemcached is built with SASL support. We suggest all users migrate to an up to date version of Ubuntu.
Any Ubuntu 14.04 LTS users may have noticed that the provided libmemcached package doesn’t support SASL authentication. This is a major issue as it means that any memcache client that depends on libmemcached (which is a lot!) doesn’t work with MemCachier or similar services out-of-the-box as they can’t authenticate with our servers.