4 ms·

You don't have to "be Google" to benefit from caching. An e-commerce site that is more responsive sells more. One reason for using caching in a website is havi

by laut 17y ago

You don't have to "be Google" to benefit from caching. An e-commerce site that is more responsive sells more. One reason for using caching in a website is having less load so that you can serve more visitors. Another is simply to give each visitor an experience with a faster website. If you can cache entire pages and bring a response down from say 300ms to 30ms that makes a big difference.

nostrademons 17y ago
I think the point is that premature caching can sweep algorithmic problems under the rug. You will eventually get around to caching things to improve performance. But if if you cache first, you might never get around to improving the algorithmic bottlenecks, since they're obscured by the cache. A day with a profiler can often result in many-fold speedups. It's not unusual for certain naively-written subsystems to speed up by 1000-fold once they've been profiled and optimized. (Often as a result of local caching - that's the "layered caches" the article was talking about.) You want to speed up the subsystems first, then cache them, not cache them and try to speed them up.
- peterwwillis 17y ago
  I think the point should be, if you're caching really really well, algorithmic problems will not matter. Why? I help to admin a site which is algorithmically shitty yet performs big feats of performance and makes bank. Making bank is the goal. If you can accomplish it even with a shitty algorithm via caching, do that. And honestly, for most horizontally-scaled systems i've seen it's not difficult to "turn down the cache" and watch for load issues. And the best way to debug problems (such as algorithm limitations) is by knowing the hard limits of every facet of your system and comparing against current use metrics. Time-consuming but not very complex.
  - laut 17y ago
    I agree. If algorithms are slow, it doesn't matter as long as they are fast enough. You should not spend time prematurely optimizing for performance that you don't need, if you can more easily use caching to give you real, experienced performance. If you want to optimize uncached performance you can turn off cache in a development/staging environment. If you run a website that is in business do not give your visitors bad performance (uncached) on purpose.
  - hartror 17y ago
    Exactly, what people seem to be doing is mistaking beautiful elegant code as the aim which it isn't. Sure we all love fast well designed code but all we care about is getting the users page to them as fast as possible with the minimum fuss. If it takes more than one line to write or read or invalidate your cache you are doing it wrong (or your framework is doing it wrong). (Same with your split tests, you split test right? . . right?).
    - prodigal_erik 17y ago
      Doing it in one line sounds like accessing a single cache slot at a time. We found we're a lot better off collecting the set of cache slots we need and then fetching them all in parallel, rather than waiting until we have the result for slot #1 before we can even start the request for slot #2. Every transaction is at least two context switches, sometimes worse.
  - jasonkester 17y ago
    I guess the ultimate point is to not have to buy more hardware. Caching and Profiling are both ways to push back that "buy another box" date, and the cool thing is you get to multiply them together. Unfortunately, as others have mentioned here, if you do Caching first, it sometimes makes it harder to do the Profiling bit later on. The reverse is definitely not true, so it makes sense to do it in that order. So yeah, making money is the ultimate goal, as is not letting money go out the door. Apologies if it sounded like I'm in favor of premature optimization. I guess I needed to be more clear with "Step 3: Wait until something presents itself as a bottleneck".

by laut 17y ago

nostrademons 17y ago

I think the point is that premature caching can sweep algorithmic problems under the rug. You will eventually get around to caching things to improve performance. But if if you cache first, you might never get around to improving the algorithmic bottlenecks, since they're obscured by the cache. A day with a profiler can often result in many-fold speedups. It's not unusual for certain naively-written subsystems to speed up by 1000-fold once they've been profiled and optimized. (Often as a result of local caching - that's the "layered caches" the article was talking about.) You want to speed up the subsystems first, then cache them, not cache them and try to speed them up.

peterwwillis 17y ago
I think the point should be, if you're caching really really well, algorithmic problems will not matter. Why? I help to admin a site which is algorithmically shitty yet performs big feats of performance and makes bank. Making bank is the goal. If you can accomplish it even with a shitty algorithm via caching, do that. And honestly, for most horizontally-scaled systems i've seen it's not difficult to "turn down the cache" and watch for load issues. And the best way to debug problems (such as algorithm limitations) is by knowing the hard limits of every facet of your system and comparing against current use metrics. Time-consuming but not very complex.
- laut 17y ago
  I agree. If algorithms are slow, it doesn't matter as long as they are fast enough. You should not spend time prematurely optimizing for performance that you don't need, if you can more easily use caching to give you real, experienced performance. If you want to optimize uncached performance you can turn off cache in a development/staging environment. If you run a website that is in business do not give your visitors bad performance (uncached) on purpose.
- hartror 17y ago
  Exactly, what people seem to be doing is mistaking beautiful elegant code as the aim which it isn't. Sure we all love fast well designed code but all we care about is getting the users page to them as fast as possible with the minimum fuss. If it takes more than one line to write or read or invalidate your cache you are doing it wrong (or your framework is doing it wrong). (Same with your split tests, you split test right? . . right?).
  - prodigal_erik 17y ago
    Doing it in one line sounds like accessing a single cache slot at a time. We found we're a lot better off collecting the set of cache slots we need and then fetching them all in parallel, rather than waiting until we have the result for slot #1 before we can even start the request for slot #2. Every transaction is at least two context switches, sometimes worse.
- jasonkester 17y ago
  I guess the ultimate point is to not have to buy more hardware. Caching and Profiling are both ways to push back that "buy another box" date, and the cool thing is you get to multiply them together. Unfortunately, as others have mentioned here, if you do Caching first, it sometimes makes it harder to do the Profiling bit later on. The reverse is definitely not true, so it makes sense to do it in that order. So yeah, making money is the ultimate goal, as is not letting money go out the door. Apologies if it sounded like I'm in favor of premature optimization. I guess I needed to be more clear with "Step 3: Wait until something presents itself as a bottleneck".