<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 20 Oct 2014, at 14:10, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 20 October 2014 12:59, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br><blockquote type="cite">HSEARCH-1699 looks good. A few comments.<br><br>Maybe from a user point of you we want to expose the number of ms the user is ok to delay a commit due to indexing. Which would mean that you can wait up to that number before calling it a day and emptying the queue. The big question I have which you elude too is whether this mechanism should have some kind of back pressure mechanism by also caping the queue size.<br></blockquote><br>Gustavo is implementing that for the ASYNC backend, but the SYNC<br>backend will always block the user thread until the commit is done<br>(and some commit is going to be done ASAP).<br>About to write a mail to hibernate-dev to discuss the ASYNC backend<br>property name and exact semantics.<br></div></blockquote><div><br></div><div>I understand that the sync mode will block until the commit is done. what I am saying is that for HSEARCH-1699 (SYNC) (and probably also for the ASYNC mode), you can ask the user “how much more” is he willing to wait for the index to be committed compared to “as fast as possible”. That becomes your window of aggregation. Does that make sense?</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite"><br>BTW, in the following paragraph, either you lost me or you are talking non sense:<br><br><blockquote type="cite">Systems with an high degree of parallelism will benefit from this, and the performance should converge to the performance you would have without every doing a commit; however if the frequency of commits is apparoching to zero, it also means that the average latency of each operation will get significantly higher. Still, in such situations assuming we are for example stacking up a million changesets between each commit, that implies this solution would be approximately a million times faster than the existing design (A million would not be realistic of course as it implies a million of parallel requests).<br></blockquote><br>I think you can only converge to an average of 1/2 * (commit + configured delay time) latency wise. I am assuming latency is what people are interested in, not the average CPU / memory load of indexing.<br></blockquote><br>I'm sorry I'm confused. There is no configured delay time for the SYNC<br>backend discussed on HSEARCH-1699, are you talking about the Async<br>one? But my paragraph above is strictly referring tot the strategy<br>meant to be applied for the Sync one.<br></div></blockquote><div><br></div><div>There is a delay. it is what you call the "target frequency of commits“. And my alternative that i proposed is not su much a frequency rather than how much more you delay a flush in the hope of getting more work in.</div><div><br></div><div>In your model of a fixed frequency, they the average delay is 1/2 * 1/frequency + commit time.</div><div>Or do you have something different in mind?</div></div></body></html>