Geek Answers Handbook

When not to use memcache

We currently have a site that makes many api calls from our parent site for user details and other data. We plan to cache all the details on our side. I plan to use memcache for this. since this is a live site, and therefore we expect more heavy traffic in the coming days (not like FB, but again my server is also not like them;)), so I need your opinion on what problems we may be to face if we go for memcache and cross-views, why don't we go for it. Any other alternative will also help.

+4
source share
4 answers

https://github.com/steveyen/community-site/blob/master/db_doc/main/WhyNotMemcached.wiki

Memcached is awesome! But not for every situation ...

  • You have objects larger than 1 MB.
  • You have keys larger than 250 characters.
    • If so, maybe you are doing something wrong?
    • And see this key size distribution section for suggestions.
  • Your hosting provider will not let you start memcached.
    • If you are working on a low-level virtual private server (machine slice), virtualization technology such as vmware or xen might not be a great place to start memcached. Memcached really wants to capture and manage a bunch of memory - if that memory is replaced by the OS or the hypervisor, performance will go away. However, the use of virtualization is simple to facilitate deployment in dedicated boxes.
  • You work in an unsafe environment.
    • Remember that anyone can only telnet connect to any memcached server. If you are in a common system, watch out!
  • You want perseverance. Or a database.
    • If you really want memcached to have an SQL interface, you probably need to rethink your understanding of caching and memcached.
+14
source

You must first implement a common cache level for API calls. Inside the caching layer, you can change the strategy you want to use. If you see that memcache is not suitable, you can actually switch (and / or check how it works compared to other backends).

Even better, you can easily copy this assembly to the file system (which also has several backends), without the hindrance to rely on another daemon, so let's start with caching - maybe the file system is already enough for your caching needs?

+2
source

Memcache is fast, but it can also use a lot of memory if you want to get the most out of it. Whenever you click on a disk for I / O, you increase the latency of your application. Pull out frequently accessed items and put them in memcache. For my large-scale deployments, we cache sessions there because the database is slow as well as file system session storage.

The recommendation for adding to your stack is APC. It caches PHP files and reduces the overall memory usage of the page.

+2
source

Alternative: Redis

Memcached is obviously limited by your available memory and will begin to flush data when the memory threshold is reached. You might want to look at redis , which is as fast (faster in some tests) as memcached, but allows you to use both volatile and non-volatile keys, more complex data structures and the ability to use virtual memory to enter Least Recent Used (LRU key values) ) to disk.

+2
source

More articles:


All Articles