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 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
