Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm considering the architecture for a web application. It's going to be a single page application that updates itself whenever the user selects different information on several forms that are available that are on the page.

I was thinking that it shouldn't be good to rely on the user's browser to correctly interpret the information and update the view, so I'll send the user's choices to the server, and then get the data, send it back to the browser, and update the view.

There's a table with 10,000 or so rows in a MySQL database that's going to be accessed pretty often, like once every 5-30 seconds for each user. I'm expecting 200-300 concurrent users at one time. I've read that a well designed relational database with simple queries are nothing for a RDBMS to handle, really, but I would still like to keep things quick for the client.

Should this even be a concern for me at the moment? At what point would it be helpful to start using a separate caching service like Memcached or Redis, or would it even be necessary?

I know that MySQL caches popular queries and the results, would this suffice?

share|improve this question
At the point where you need to start speeding things up, assuming you've covered the other possibilities for performance optimizations.. – Robert Harvey Oct 22 '13 at 23:31
up vote 10 down vote accepted

You need caching when you have a problem that can be solved by caching. That problem may be too much processor usage on the DB; if it is then MySQL caching is going to help you a lot -- but maybe not enough, it depends what else is going on. Or it could be that your network connection from the application instances to the DB are getting overloaded.

In that case, MySQL caching isn't going to do much for you; it'll cache the response but you still need to go to the database to get it. It could be that the bottleneck is server processor, or even bandwidth between the server and the outside world, or memory usage, or number of threads, or number of handles, or any number of other things -- some of which cannot be solved by caching at all. Memory usage COULD be made worse.

Donald Knuth is quoted a lot in programming circles. Often badly or invalidly. But in the case of "Premature optimisation is the root of all evil," he at least had a point, if slightly dramatically stated.

When you're thinking about the general architecture of your new app, think about two things: reporting and extensibility. There are plenty of AOP-style caching frameworks out there that can cache the results of any method; so as long as you keep database access well-isolated, it'll be extensible enough to ask the question of caching later.

The question you should be asking now is this: How do I know, on the day that I first get techcrunched, and my application or the database or the network cannot cope with the load, which layer of the application is the bottleneck, so I can fix it?

You really should be looking for metrics and reporting frameworks long before you ask questions about caching.

share|improve this answer
Thank you very much for the information. I'm just starting to get a handle on these things. – Zaemz Oct 23 '13 at 0:18

Your Answer


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.