On Aug 1, 2008, at 18:50, Adam Jacob wrote:

> On Fri, Aug 1, 2008 at 12:37 AM, Johan Liseborn
> <johan.liseborn@gmail.com> wrote:
>> AFAIU, when you add new documents and then evaluate a view including
>> those documents, indexing will happen, but only for the newly added
>> documents (i.e. already indexed documents will not be re-indexed). I
>> believe this means that the time to index will be, in some way,
>> proportional to the number of *new* documents. I believe I have  
>> seen a
>> big-O "number" for this somewhere, but I don't remember right now if
>> it is O(n), O(log n), or something else (I am sure someone else on  
>> the
>> list can answer that :-).
>>
>> As can be seen from the results, when CouchDB had to index the 10.000
>> new documents, it took about 13 minutes to get the result, but when
>> all the documents had been indexed, the answer came back in 0.7
>> seconds. Having to index 10 documents did not take that long, giving
>> an answer in 1.2 seconds.
>
> I did some totally off-the-cuff benchmarking with Varnish (a caching
> HTTP reverse proxy) in front of CouchDB.  It works entirely as
> expected - Varnish returns lightning fast (<30ms) very consistently
> (20ms in the 50%, 35ms in the longest.)
>
> With Varnish, you can also add PURGE support for a given URL.
>
> This means that, if those compute times are egregious, and you can
> suffer your data being a bit out of date, it would be trivial to
> create a system that does:
>
> Reads...
> User -> Varnish -> CouchDB
>
> Writes...
> User->Varnish->CouchDB->PURGE for entry->Queue for view
> re-indexing->PURGE for views
>
> Essentially ensuring that all your reads always return as quickly as
> possible, masking any possible delay in index queries on bulk updates
> (assuming stale data for 10 minutes is ok.)

?update=false would be the CouchDB-only solution for that.

Cheers
Jan
--