Not sure why your views are timing out, but from my current
understanding views are incrementally updated with modifications but
only incrementally updated on a call to that view.
One hypothesis is that after the thousands of inserts the next view
call is taking a long time doing the incremental updates to the view
since the last time it was called.
Are you using the javascript spodermonkey viewserver(default) or
another one? Check the complexity of the view and possibly minimize
the view's complexity.
As a final thought iirc when querying a view in a design document, all
views in that designdocument are called. Is it possible you might have
unrelated views in the same design document?
I'm not sure, but I think the pattern here is you put views most
likely to be called near to each other in the design document, say
blog summaries view followed by full content view, and have less
related views in a different design document, say for a list of
authors or a tag list.
Hope this helps.
Cortland Klein <[EMAIL PROTECTED]> +1 408 506 9791
http://pixelcort.com/
Sent from my iPhone
On Apr 27, 2008, at 4:04 PM, Guby <[EMAIL PROTECTED]> wrote:
Hello dear Couchers
I understand that the views are indexed the first time they are
accessed and as far as I know there is no way to turn on view
updating on document save. I really don't understand the reasoning
behind this behavior. The advantage of the pre-populated/indexed
views are that they are blazingly fast to query and access, but that
advantage disappears when the first request after a document update
has to regenerate the view first!
I am currently building a web app where the background processes
perform a lot of writes to the database. The time it takes to write
a document is not critical for me. What is critical though is the
time it takes to load web pages for the end user that require
content from the database.
In some situations the background processes add thousands of
documents to the database within a short period of time, and when
the user tries to access a page after such an update the view
querying sometimes takes minutes and as a consequence of that the
browser times out... Not a recipe for happy customers...
The only solution I can see at the moment is to create a worker that
queries the database whenever it is told that there has been a
document update, but that seems really stupid and unnecessary. And
in my case, running on a smallish VPS, a big waste of resources
having an extra working doing something the database itself could
just as well have done. It also requires a lot of extra coding
notifying the worker whenever I update or create a document
throughout my app.
I am sure you have reasons for having implemented the views the way
you have, but I would be really interested to hear why it has been
done this way!
My wishes are for an optional updating of views on save feature! In
some cases that might regenerate a view several times without it
actually being accessed in between, but that is a tradeoff I can
live with, slow views on the other hand is something I can not!
All the best
Sebastian
