Home/ Questions/Q 7669497
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T15:36:25+00:00

I am considering enabling Memcache support for my large-scale REST service. However I have

  • 0

I am considering enabling Memcache support for my large-scale REST service. However I have some questions regarding best approaches for these key-value stores.

The setup:

  • A database wrapper which has functions for select, update and etc.
  • A REST framework which contains all the API functions (getUser, createUser and etc.)

In my head, the ideal approach would be to integrate the Memcache in the database wrapper so, for example, every SQL query would get md5-hashed and saved in the cache (this is btw what most online resources suggests). However, there is obviously a problem with this approach: if a search query has been cached, and one of the users from the search result has been updated after the cached result, this wont reflect in the next request (because it is now in the cache).

As I see it I have several ways of handeling this:

  • Implement the Memcache in the REST framework for each function (getUser, createUser etc) and thereby explicit handle the updating of the cache etc. if users gets updated. This could end up in redundant code.
  • Let the cached values expire very quickly and live with the fact that some requests shows old cached values.
  • Do a more advanced implementation of the Memcache in the database wrapper so that I can identify which parts(e.g. users) to update in e.g. a search request.

Could you guide me to which of the following, or a complete another approach, to take?
Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Enabling cache for a web application is not something to take lightly.

    Maybe you have done that already bit… I recommend you first come up with a goal based on business needs or forcast (ex: must accept 1000 requests per seconds) then properly stress-test your system to have numbers before you start changing anything and then identify your bottleneck.

    I usually use profiling tools such as HXProf (by facebook).

    Caching all your data to mirror your database might not be the best approach.

    Find out how big you can allocate for your cache. If your architecture only allow you to allocate 100MB for your memcache, then it will affect your decision about what you cache and how long you cache it.

    The best cache is to cache forever. But we all know that data changes. You can start by caching data that is requested often and requires the most resources to fetch.

    Always try to make sure you are not working on improving something that will get you low improvement.

    Without understanding your architecture in depth, it would be hazardous for anyone to recommend a caching strategy that best fit your needs.

    Maybe you should cache the resutling output of your web services instead? Using a reverse proxy for example (What @Darrel is talking about) or using output buffering…

    Optimize your database queries before you think about caching. Make sure your use a PHP Op cache (like APC) and all those things that are standard practice.

    If you want to cache data and prevent stale/old data from being served, the trick is to identify your data (primary key maybe?) and when the data is updated or deleted, you delete or update the cache for that identifyer.

    <?php
// After inserting into DB, you can also put it in the cache
$memcache->set($userId, $userData);

// After updating or deleting the user, you update or delete the data
$memcache->delete($userId);

    A lot of site will show stale data. When I am on stackoverflow and my reputation is increased and then I got in the stackoverflow chat, the reputation shown is my old reputation. When I got a reputation of 20 (reputation required to chat) I still could not chat for another 5 minutes because the chat system had my old reputation data and did not yet know my reputation had increased enough to allow me to chat. Some data can be stale while other type of data should never be stale. Consider that when caching data.

    Conclusion

    Your approaches can all be valid depending on the factors that I talk about above. In fact, you can use a combination of those for all the different type of data you want to cache and how long it is acceptable to show old data for them. Maybe the categories or list of countries (since they do not change often) can be cached for a long time while the reputation (or whatever data changes all the time for all users) should be cached for a short period only.

    • 0