2

I'm working on a web app that's not even online yet. Is implementing memcache or memcached as of right now a bit premature? Should I use it only if:

  • the web app is up, and
  • the database is having a poor performance due to a high traffic/load?

Or is better to implement during development?

Also, in which cases is using a caching interface unnecessary or even disencouraged?

Adam Wenger
  • 17,100
  • 6
  • 52
  • 63
federico-t
  • 12,014
  • 19
  • 67
  • 111
  • Duplicate in spirit: http://stackoverflow.com/questions/2978460/practical-rules-for-premature-optimization – Will Bickford Dec 10 '11 at 06:54
  • Actually no. My question wasn't "what's premature optimization?" but "is using caching interfaces before the site is up considered premature optimization?" – federico-t Dec 10 '11 at 07:19
  • Yeah I know - hence the 'in spirit' - the key being that unless you've profiled and tested you can't really decide on any optimization techniques. – Will Bickford Dec 10 '11 at 07:23

3 Answers3

4

Know Your Problem Space

See memcached's own wiki:

Can using memcached make my application slower?

Yes, absolutely. If your DB queries are all fast, your website is fast, adding memcached might not make it faster.

Get It Working First

Any optimization before you have a stable, working product is premature. You'll spend all your time fiddling with knobs that have zero performance impact on your application.

Your best bet is to get it into a working state and then do several things:

Profile performance

Until you gather performance data you'll have no idea where your bottlenecks truly are. Most likely they're in areas you haven't considered.

Identify Optimization Payoffs

Evaluate each problem area for potential performance improvements. Prioritize the areas that will give you the best ROI (return on investment). In some cases the best ROI may be more hardware.

Implement Optimizations

Once you've identified what needs to be optimized, create a plan and implement it.

Sources

Community
  • 1
  • 1
Will Bickford
  • 5,381
  • 2
  • 30
  • 45
  • Thanks for your answer. I also think that I'm worring about things that probably won't be the biggest problem once I put up the page, I'll take care of it when I _really_ have to. – federico-t Dec 10 '11 at 07:17
0

Not at all, memcache is just an external storage (which is fast and distributed),
no more or no less

Also, in which cases is using a caching interface unnecessary or even disencouraged?

probably should not use for crucial data, such as a transaction

ajreal
  • 46,720
  • 11
  • 89
  • 119
0

Actually, this question has two answers:

First, as Will Bickford mentioned, is that you have to avoid premature optimization. You have to have a working application to determine places that may benefit from performance improvements. Only after that you can try to apply caching.

Second is designing your application for future load. This means that before you start coding, you should try to answer this question: "How will my design change if the application must handle load, let's say, 10,000 times more than it is planned now?" This usually leads to a more advanced (as in though-through) design that accommodates scaling to multiple servers, and with that comes the need to share state between the servers, hence the distributed caching. If you don't answer this question, there is a good chance you'll have to re-write your application sooner or later.

In other words, design for future, implement for today.

Hope this helps.

Slava Imeshev

Slava Imeshev
  • 1,360
  • 10
  • 14