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?

  • 3
    At the point where you need to start speeding things up, assuming you've covered the other possibilities for performance optimizations.. Commented Oct 22, 2013 at 23:31

1 Answer 1


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.

  • Thank you very much for the information. I'm just starting to get a handle on these things. Commented Oct 23, 2013 at 0:18

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.