Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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. –  PersonalNexus Dec 21 '11 at 6:14
add comment

2 Answers

up vote 6 down vote accepted

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

share|improve this answer
1  
+1 for bullet #2. –  mouviciel Dec 21 '11 at 10:15
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 Dec 21 '11 at 19:14
add comment

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.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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