It’s difficult to see how we’d significantly improve list/show performance but the attempt should at least be made.
On caching, we should give the user more control. Today, we send must-revalidate with almost all requests. While that is correct for a database, it’s not configurable. The client should be given more freedom here. On the ETag’s we currently send, they are supposed to allow correct caching; they stay the same when the view does / they change when the view does. In 2.0, there’s a bug that breaks this for views, it currently sends a random UUID value. We should fix that, unless we agree that a view response can send headers that allow for more caching. I thought show/list correctly did the etag / 304 dance but it’s possible that isn’t there or has been broken. B. > On 9 May 2015, at 08:00, Giovanni Lenzi <[email protected]> wrote: > > 2015-05-08 17:56 GMT+02:00 Alexander Shorin <[email protected]>: > >> One idea was already discussed on ML, IRC and pretty trivial: provide >> cache-friendly show/list functions with deterministic output. Mostly, >> could be solved by using stateless template engine like mustache on >> server side and side-effect less logic. The results could be cached on >> disk as like as views ones does and all show/list requests are turns >> into building and serving static content from disk. >> > > Thanks for letting me know. Sounds nice. > > Now that you told me cache, I had a flashback.. At Smileupps, in the past, > in order to efficiently interact with search engine spiders, we were trying > to implement the "If-Modified-Header" ( > https://www.feedthebot.com/ifmodified.html), using show and list functions. > But we faced what seemed like an imposed couchdb restriction... It seemed > not possible to return correctly a 304 status-code. Even if we returned it > from the show function, it was not the real code sent to client. > > I'm sharing this experience, just to not lose it.. I am not surely > searching an answer on that. > > > >> Another is to improve communication with query server, thought, it's >> less trivial than the former one. >> >> -- >> ,,,^..^,,, >> >> >> On Fri, May 8, 2015 at 6:48 PM, Giovanni Lenzi <[email protected]> >> wrote: >>> Hi everyone, >>> >>> on the marketing@ list has emerged the need for improving ddocs >> performance. >>> >>> @ermouth said: Also couchapps generally have very poor perfomance – >> because >>> json >>> serialization/deserialization while transmitting data from map to _list >> and >>> _show functions is slow. >>> >>> What do you think are ddocs performance bottlenecks and is there a way to >>> fix them? >>> >>> >>> -- >>> Giovanni Lenzi >>> www.smileupps.com >>> Smileupps Cloud App Store >> > > > > -- > Giovanni Lenzi > www.smileupps.com > Smileupps Cloud App Store
