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 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.