Hi guys, I've some updates. Using an queue in the middle improved performance. Furthermore I've extended the asynchronous also to transactions.
Please could you re-test last version 2.0-M2-SNAPSHOT? Lvc@ ᐧ On 24 September 2014 11:31, Luca Garulli <[email protected]> wrote: > 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.
