Hi Luca, I tested this and now get 0.24sec average inserts, which is the fastest distributed performance I've experienced yet.
There still seems to be communication with the remote node before releasing the client though. Regards, - Ben On Wednesday, September 24, 2014 1:24:23 AM UTC+2, Lvc@ wrote: > > Hi Ben, > I've pushed a new version that reads the configuration from file > *default-distributed-db-config.json*, by adding: > > * "executionMode": "asynchronous",* > > Lvc@ > ᐧ > > On 23 September 2014 21:53, <[email protected] <javascript:>> wrote: > >> Hi Luca, >> >> Yes, I'm aware of that... >> >> My reference to 1.7.9 was only concerning Christian's suggestion. >> >> When I tested 2.0-M2, i still have no improvement. Does it need to be >> activated for use in the console or binary interface? >> >> I do not have Java apps for creating documents. >> >> Regards, >> - Ben >> >> On Tuesday, September 23, 2014 9:14:57 PM UTC+2, Lvc@ wrote: >>> >>> Hi Ben, >>> This is supported only in 2.0-M2. >>> >>> Lvc@ >>> >>> ᐧ >>> >>> On 23 September 2014 21:03, <[email protected]> wrote: >>> >>>> Hi Christian, >>>> >>>> Tried your suggestion too on 1.7.9, unfortunately it hasn't had any >>>> influence even though it looked promising. >>>> >>>> Regards, >>>> - Ben >>>> >>>> >>>> On Tuesday, September 23, 2014 8:48:00 AM UTC+2, Christian Laakmann >>>> wrote: >>>>> >>>>> Hi all, Luca, >>>>> >>>>> it seems as if you wait for synchronous responses from _all_ available >>>>> Nodes, even if quorum is set to 0. In >>>>> ODistributedResponseManager#collectResponse, >>>>> this code handles the notification of waiting threads after all expected >>>>> responses have been received. >>>>> >>>>> if (receivedResponses >= expectedSynchronousResponses && >>>>> (!waitForLocalNode || receivedCurrentNode)) { >>>>> if (completed || isMinimumQuorumReached(false)) { >>>>> // NOTIFY TO THE WAITER THE RESPONSE IS COMPLETE NOW >>>>> notifyWaiters(); >>>>> } >>>>> } >>>>> >>>>> My expectation would be, that #isMinimumQuorumReached() were called as >>>>> part of the first IF, i.e.: >>>>> >>>>> if (completed >>>>> || isMinimumQuorumReached(false) >>>>> || (receivedResponses >= expectedSynchronousResponses && >>>>> (!waitForLocalNode || receivedCurrentNode))) { >>>>> // NOTIFY TO THE WAITER THE RESPONSE IS COMPLETE NOW >>>>> notifyWaiters(); >>>>> } >>>>> >>>>> From my understanding, this would notify the waiting thread that >>>>> pushed the task as soon as the quorum is reached or all responses from >>>>> the >>>>> available nodes have been collected. >>>>> >>>>> Cheers, >>>>> Christian >>>>> >>>>> >>>>> On Tuesday, 23 September 2014 00:58:55 UTC+2, [email protected] wrote: >>>>>> >>>>>> Hi Luca, >>>>>> >>>>>> Since I've been hung out to dry, I've toyed around with the orientdb >>>>>> sources. I was able to establish that the bottlenecks are indeed >>>>>> sendRequest and send2Nodes. Removing sleeps in the latest 1.7.9 release >>>>>> already provided a 50% improvement (From ~1.2sec down to ~0.55sec.). >>>>>> Clearly we have different views on what is asynchronous. In your >>>>>> methods, >>>>>> you inarguably wait for a response from the nodes before giving a >>>>>> response >>>>>> to the client. IMHO asynchronous replication should update the local >>>>>> database, respond to the client and care about the rest later. I believe >>>>>> the replication methodology needs a rethink. Whilst in may be suitable >>>>>> to >>>>>> LAN environments, it is certainly not suitable for WAN. I still wonder >>>>>> if >>>>>> this is intended or even if it has ever been tested. I see examples with >>>>>> europe and usa nodes with sharding, etc.. but I can't believe such >>>>>> delays >>>>>> are accepted or the norm. Other technologies can do it, so should >>>>>> OrientDB. >>>>>> >>>>>> Anyway, enough of my ramblings.... Have a good evening. >>>>>> >>>>>> Regards, >>>>>> - Ben >>>>>> >>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OrientDB" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
