Hi Ben, I found a bottleneck in Hazelcast: https://github.com/hazelcast/hazelcast/issues/3661.
I could put a queue between ODistributedStorage and HZ. Let me try it now. Soon a new push. Lvc@ ᐧ On 24 September 2014 10:59, <[email protected]> wrote: > 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]> 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]. >>> 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. > -- --- 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.
