Announcements, New Features, and How Tos
If you’re using Memcache in Java, chances are you’re using the SpyMemcached client. It has been the most popular Java client for years. Unfortunately, at MemCachier we have had a lot of customer reports about problems with SpyMemcached. For this reason we now recommend to use XMemcached with Java.
In light of recent DDoS attacks involving memcached servers several customers have asked us about MemCachier’s vulnerability to this type of attack. At MemCachier, we are not vulnerable to these kinds of attacks because we use a custom multi-tenant implementation of the memcached protocol that is optimized for security, reliability, and performance as a cloud service.
As part of the infrastructure improvements that we started in June, we’re going to be merging some of the clusters of EC2 instances that host MemCachier caches, starting in the next couple of weeks. This will not affect all customer caches, and the impact during the merge process will be minimal, but we wanted to be up-front about the fact that this is happening.
This week we exposed the API feeding our analytics dashboard so you can hook into some of its more convenient features. With our new public API, you can retrieve statistics and historical data to analyze your cache’s activity. You’ll be able to add, edit, promote, and delete credentials. You’ll also have the option to trigger a cache flush command via the API. This means you can now integrate your cache into other processes, such as setting up an HTTP deploy hook through Heroku. Let’s walk through what that would look like.
A key feature that MemCachier offers its clients is the ability to use multiple proxy servers to access their cache. This is important because most issues that clients experience are related to network delays or general connectivity. In such cases a memcached client can fall back to a different proxy and still have access to the entire cache.
In this article, we’ll describe some of the performance impacts of the AWS infrastructure migration we performed recently.
In April, we announced our plan to migrate all of our Amazon Web Services (AWS) clusters to new VPC-based infrastructure on Elastic Cloud Compute. As we wrapped that up this past month, we documented the process to migrate a large multi-tenant, distributed cache service online as well as some lessons learned.
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.