Hi Marcello, Thanks for information. In fact the information about the data being updated to the last record is required, with the condition that end user should not have a notifiable waiting ime (not more than 20 sec). For testing, I did measurements with CouchDB-1.0.1 and CouchDB-1.1.0 for the clean installation database on Ubuntu machine(single core) with only CouchDB running on the machine. A writer from my another machine writes documents to the database. I observed a significant difference between the writing speed as follows:
CouchDB-1.0.1 CouchDB-1.1.0 Writing speed 5 Docs/sec 20-25 docs/sec I am sticking with CouchDB-1.0.1 for my project now as I am using it for quite sometime and it is stable. For Windows it crashed (we know that Windows is not officially supported platform). so for now, I am not using 'stale=update_after'. On Thu, Jun 16, 2011 at 9:36 AM, Marcello Nuccio <[email protected]>wrote: > 2011/6/16 Yogesh Khambia <[email protected]>: > > Hi Marcello, > > > > Thanks for the tip. > > I will be testing with CouchDB-1.1 soon. > > One point I want to add: > > In my case as the database is being updated quite often, the user is > > interested in the view on the latest data available at any time. Querying > > the view with 'stale=update_after' parameter will result in stalling the > > view and then rebuilding the view index, therefore, it will not give the > > view on the latest data. > > It will give the view on the latest indexed data and it will ensure > that the index is kept updated. It's a trade-off. What is the most > important for your users: fast response time or information updated to > the last second? > > Marcello > > > > > On Thu, Jun 16, 2011 at 7:40 AM, Marcello Nuccio > > <[email protected]>wrote: > > > >> Hi Yogesh, > >> I cannot answer your questions, but I think you should repeat your > >> tests with CouchDB-1.1 and querying the view with `stale=update_after` > >> parameter. > >> > >> Read > >> > http://docs.couchbase.org/couchdb-release-1.1/index.html#coudhdb-release-1.1-updateafter > >> for more information. > >> > >> Bye, > >> Marcello > >> > >> 2011/6/16 Yogesh Khambia <[email protected]>: > >> > Hi all, > >> > > >> > Currently, I am doing performance tests with database in CouchDB > 1.0.1, > >> > where a script is continuously writing single documents to the CouchDB > >> > database. > >> > I had the issue of the user being penalized for reading the view in > >> CouchDB > >> > database, by updating the view indexes.To improve on the latency for > the > >> > view index generation, I wrote a function which generates the view > >> indexes > >> > for each new update made to the database. > >> > The latency for view index creation has been improved. However, I read > >> from > >> > the FAQ on the CouchDB wiki that "The reason not to integrate each doc > as > >> it > >> > comes in is that it is horribly inefficient and CouchDB is designed to > do > >> > view index updates very fast, so batching is a good idea." > >> > It will be really helpful if somebody can answer me on following: > >> > > >> > - If view index generation for each new single document insert is not > a > >> > good approach? > >> > > >> > - How does the single document insert and bulk document insert affect > the > >> > CouchDB view generation, where: > >> > > >> > 1. a daemon script updates view index for each new document insert. > >> > 2. a daemon script updates view index for bulk document > >> > > >> > Thank you. > >> > > >> > > >> > -- > >> > Best Regards, > >> > Yogesh Khambia > >> > Postgraduate Design Engineer > >> > Mobile: +31 626 217 381 > >> > Email: [email protected] > >> > > >> > > > > > > > > -- > > Best Regards, > > Yogesh Khambia > > Postgraduate Design Engineer > > Mobile: +31 626 217 381 > > Email: [email protected] > > > -- Best Regards, Yogesh Khambia Postgraduate Design Engineer Mobile: +31 626 217 381 Email: [email protected]
