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

Let's say I have a web service that is poorly written and inefficient, but it's output is cached so there's no bottleneck. Do you just leave it? Would you go as far as to take deliberate shortcuts knowing that performance problems will be masked?

share|improve this question
Caching is not a magic bullet in general. Is it in your case? – delnan Dec 12 '12 at 17:29
How long is the data cached? How likely is the average user going to see a cache miss? Are you warming your cache before user's see slow queries? Your question isn't answerable without details. – Steven Burnap Dec 12 '12 at 17:45
Every time you query that service, everything else on your server will be a bit slower until it finishes running. – Brian Dec 12 '12 at 17:56
I'm not talking about an actual application I'm working on right now. I want to discuss the pros and cons. – jiggy Dec 12 '12 at 18:19
@jiggy: My point is that one con of having an expensive web service is that it slows down the hosting server. – Brian Dec 12 '12 at 18:30

In the short term, yes, it's okay.

Knowing that over the long term, you're going to get burned. So no, it's really not okay.

Yes | No really depends upon your shop; the amount of backlog that is present; and just how critical this particular function is.

Caching to mask performance issues is a crutch, and is a form of technical debt. The real problem comes about when you have to start making changes or updates within that area. The cache represents the first layer of band-aids to this problem. Future changes will result in more and more band-aids until you fix the root of the problem.

If it can be reasonably easily fixed within the constraints of your environment, then it should be fixed. Especially so if it's a volatile area.

If you're considering taking shortcuts knowing that you can use the crutch of caching, then you've already headed down the wrong path.

share|improve this answer

As always, it depends. Caching can improve performance anywhere between "whopping" and "not at all", or even reduce performance.

If your resource it read often but seldom changed, caching is usually a good idea, especially when generating it is non-trivial. If, however, it changes every few requests, there is no point caching it.

Also, it can be beneficial to use several layers of caching - e.g., a response cache at the HTTP level that serves identical responses to identical requests, a memory cache holding readily-processed data sets, another cache that holds chunks of raw data for further processing, and of course the caching that comes with your databases and filesystems. The reason why you want to cache at several levels is that there are different points at which you can match identical conditions with identical results, and you want to cache at each of these whenever it makes sense.

Another factor you need to keep in mind is that most data does not have to be available in real-time. It is often acceptable to present data that is, say, an hour old or so, even when newer data exists. If this is the case, you can generate your resource in a separate process, serving the previous version until the new one is done, then doing a fast atomic replace (e.g. by renaming a file or through an atomic database operation). This way, you always get maximum performance at all times, while you can still afford to take some time generating the resource. And, better yet, the generator can run on a different machine if necessary, so as not to bog down the web server itself. Of course it doesn't hurt to add a layer of caching on top of that; after all, serving from RAM is still an order of magnitude faster than serving from disk.

share|improve this answer

It would be grossly inaccurate to tell you that it is or it isn't okay because it is ultimately a tradeoff between implementation time and how well you wish your program to perform. I don't think it's fair to say that program performance always has priority over performance, because ultimately the software industry is a business like any other and some tradeoffs are acceptable.

However, I think the only time when it's okay to ignore poor performance for a resource that will be cached is if you plan on preloading a lot of resources you will use at the startup of the program and your cache isn't weak (you don't throw out old data in favor for new data). Users tend to have little patience for waiting times, but they also tend to be more tolerable if they expect to have to wait, such as moments when you're opening a program or you're creating a report. You can take advantage of this and load once and placing this resource in cache. Just don't combine poor performance with lazy loading, since that will create unexpected delays when the user won't expect it.

And, of course, do be sure to get around to fixing that performance problem eventually.

share|improve this answer

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.