Since JS rewrites landed in 2.0, and I use JS rewrites heavily, I discover some tricks with the new feature time to time. Despite I use patched 1.6.1 with js rewrites, tricks are suitable for at least single node 2.0 as well.
JS rewrites function runs in the context of a query server instance. QS instance is a Spidermonkey process with 64Mb of RAM by default. It‘s single threaded. Actually, seems that all query server functions of one particular design doc are executed inside one dedicated Spidermonkey instance. It means they all share global context (also it means they share one thread). Ddoc global context persists until Spidermonkey process is restarted. It happens when SM instance crashes (runs out of RAM quota, unrecoverable error happens etc), or when underlying design doc is changed. It means _list function can cache results of rendering into RAM, and _rewrite function can later quickly respond with cached version, skipping redirect to heavy map/list. Cache container is just JS closure, instantiated/accessed using built-in require(). Unlike _list, JS rewrite function does not receive req.info, it would be too slow to tap DB on each request. It means we can not invalidate cache on local sequence change (DB update) – rewrite function just does not know DB was updated. However we can use timestamp-based caching, even several seconds TTL of cache entries is enough to reduce average response time significantly (say, order of magnitude). I‘ve tested approach a little and found it very promising. Since this dirty hack is possible with _list fns only, without js rewrites, may be someone already employs it? Or at least tried? ermouth
