http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660There are actually a few already out there: https://github.com/mattdaly/node-ravendb https://github.com/csainty/node-raven See also: http://groups.google.com/group/ravendb/browse_thread/thread/501ed1b4a0b3e380?pli=1 http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment7http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment7Thu, 03 May 2012 08:35:59 GMTAyende, do you have any plans for ravendb driver for node.js ?http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment6http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment6Thu, 03 May 2012 00:30:13 GMTJanivz, We loaded all 3 million records as soon as we could, using inserts. We didn't test updates, since the process is the same in all respects.http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment5http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment5Wed, 25 Apr 2012 13:09:34 GMTAny chance u could elaborate about the specifics of the 3 million document test? how many bulk inserts/ updates over what period of time ... and such. Thank youhttp://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment4http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment4Wed, 25 Apr 2012 09:20:20 GMTDynamically adjusting the batch size reminds me of process prioritization in OSes. The basic idea being if a process uses all of its time slice, increase its time slice (up to some maximum). If the process does not use its time slice, decrease the time slice (down to some minimum). Usually, the increase and decrease are asymmetrical so that the algorithm can find an appropriate balance between the current workload vs the historical workload. I am also impressed that with a roughly 4-6 order of magnitude increase in document rate, there is only a 2 order of magnitude increase in index latency.http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment3http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment3Tue, 24 Apr 2012 14:01:27 GMTThe same can be applied (to the given limit of time) to quering a given resource for changes, or any other heavy work. If for instance a message was found in a queue, pop another one quite fast the second time, if one isn,t found, extend the period. I think that this idea is standing behind usage of Azure Queries in NServiceBus.http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment2http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment2Tue, 24 Apr 2012 10:27:32 GMTAuto-tuning is extremely convenient. Lacking this is likely to be one of the factors making MySQL users unhappy and driving the NoSQL shift.http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment1http://ayende.com/155425/the-ravendb-indexing-process-optimization-tuning-why-we-have-auto-tuning#comment1Tue, 24 Apr 2012 09:40:29 GMT