Hi Ermouth, this sounds like a bonus feature of significant value:) Together with the rewrite function this discovery would keep the couchapp enthusiasts of the community happy for a looong time, I believe.
If I understand you right, - a function in a _list of a certain ddoc called directly via the _list endpint (NOT via _rewrite) - can cache a rendered result (e.g. a html page) - for a subsequent request via _rewrite (of the same ddoc) to pick up the cached result from RAM - using a timestamp inside that _rewrite function to compare against the timestamped name of the cached result to validate that the age is within a chosen tolerance Following this 2-step approach (_list, then _rewrite).. - the _list function would have the full request context - while the _rewrite would have the limited request object available - the _rewrite and _list endpoints would need to be available Control questions - does this mean that you cannot point a vhost to _rewrite and run all calls to _list via rewrite functions? - if you have one vhost pointing to _rewrite of a ddoc and another to e.g. _list would they still share the cache? Testing this - could you give us som sinppets on how to test this, I would love to see this in action and test it towards my JS rewrite functions. br johs > On 19. mai 2016, at 00.01, ermouth <ermo...@gmail.com> wrote: > > 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
