I am writing an uber simple blogging platform. The application reads a set of static files that are the articles in the blog, and serves them up.

The only time any content on the site will change is when a new article is added, or an existing article is changed.

I intend to load 100% of the content into the applications memory, and only update it if the static files are changed. I.e. a permanent cache. For a simple blog, the static files are never going to amount to more than a few MB, so application memory wont be a problem.

Are there any reasons not to do this? And why do blogging (/other) platforms with content that only changes at set intervals not use this method?

  • What makes you think other sites don't cache aggressively? There was an episode of the Stack Exchange Podcast (don't remember which one, though, sorry) talking about how caching was used on Stack Exchange to avoid calls to the database. Commented Dec 21, 2011 at 6:14

2 Answers 2


"Are there any reasons not to do this?"

  1. Scalability. Sure, when you're using it now, the data is under a few MB. Will that always be the case? I don't think so. Especially if you expect other people to use this system.

  2. You're re-inventing the wheel. If the content is stored in files, you should just let Apache (or whatever other web server you're using) serve them up, and deal with the caching. It'll probably do a better job than whatever you come up with.

  3. It's not necessary. If the data set is small, then you should be able to get acceptable performance using MySQL, or static files served up by Apache, or any of the other ways that people normally do this. If the data set is large, then your caching scheme won't work (see #1).

  • 1
    Thanks for the responses... essentially, it seems that if the data is small enough for this to be possible, then it is not worth doing. Ty
    – mrwooster
    Commented Dec 21, 2011 at 19:14
  • 2
    #3 - Even without explicit caching, modern OSes aggressively use RAM to cache disk data, getting you what you want for zero effort. Commented Apr 27, 2015 at 0:54

Off the top of my head, I could think of a few reasons not to keep an entire site in memory:

  • The site might be too large to fit entirely in memory.
  • Even if you could technically fit it in memory, it might not be economical to do so, if only a small set of pages is accessed regularly while the rest is never looked at.
  • Having a large number of objects in memory might also slow down garbage collection (if you are programing a garbage-collected language such as Java or C#) because there are all these extra objects to check.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.