3 ms·
Exactly. Use both (with caveats), they sit at different levels. It's like cloudflare/varnish/nginx -> rack -> rails -> app
by midas007 13y ago
Exactly. Use both (with caveats), they sit at different levels.
It's like
cloudflare/varnish/nginx -> rack -> rails -> app
-> memcache
Anything you can use to take load off the DB, which in turn may hit some sort of blocking I/O call (SSD or HDD) is a very Good Thing (TM). Or a sleeping heroku dyno. ;)
- jrochkind1 13y agoThe optimizations being discussed in OP do not take any load off the db. They only reduce CPU time for AR to calculate what it's going to ask the DB for. Unless I'm misunderstanding.
- midas007 13y agoIsn't the goal that the refactored AR code is basically cleaner, which allows AR query caching to be more mergable? Not asking for the same thing twice (or N-1 or N^2-1 extra times) if has to go over the network is a good thing. Databases often aren't properly configured OOTB, especially when it comes to temporary tablespace and query caching.
- jrochkind1 13y agoSeriously, have you read the OP? The optimizations in the OP do not prevent AR from asking for the same thing more than once. They do not effect how many times AR asks for things at all, as far as they can tell. It is _not_ caching database responses. It is caching internal AR calculations only, and does not reduce the number of times AR asks for things from the DB. Unless I am misunderstanding.