Hi, No I mean that this improvement will be available only in non-distributed mode.
On Sun, Jan 3, 2016 at 10:06 PM nightrise <aelrherm...@gmail.com> wrote: > Hi Andrey, > > So are you saying that if I set it up in distributed mode, the performance > of edge creation will be a lot better? > > > On Tuesday, December 29, 2015 at 2:45:01 AM UTC-5, Andrey Lomakin wrote: > >> Hi, >> > Sorry missed your response. >> >> I meant that distribution which we are working for now, makes edges >> creation faster than in 2.1.7 version. >> It is related to non-distributed version.Is it ok for you ? >> >> Because I thought that your performance problems related to >> non-distributed version. >> >> On Mon, Dec 28, 2015 at 10:54 PM nightrise <aelrh...@gmail.com> wrote: >> >>> Any updates, Andrey? >>> >>> >>> On Monday, December 21, 2015 at 5:12:13 AM UTC-5, Andrey Lomakin wrote: >>> >>>> Hi, >>>> I think we may fix given issue of you , is it possible for you to run >>>> your benchmark from scratch on distribution which we will sent you ? >>>> >>>> On Sun, Dec 20, 2015 at 10:34 PM nightrise <aelrh...@gmail.com> wrote: >>>> >>>>> Yes Luca, as I said in my previous post, I went back to 2.1.1 as I'd >>>>> rather not update to 2.1.7 if it's not delivering scalable performance >>>>> (even if the performance is a little better). >>>>> >>>>> What I'd like to know is if there is a proper way to do what I said >>>>> above in either 2.1.7 OR in 2.1.1. >>>>> >>>>> >>>>> On Saturday, December 19, 2015 at 4:33:51 AM UTC-5, l.garulli wrote: >>>>> >>>>>> Hi, >>>>>> You say to use OrientDB v2.1.1 but this post is related to the >>>>>> v2.1.7... >>>>>> >>>>> >>>>>> Best Regards, >>>>>> >>>>>> Luca Garulli >>>>>> Founder & CEO >>>>>> OrientDB <http://orientdb.com/> >>>>>> >>>>>> >>>>>> On 16 December 2015 at 23:55, nightrise <aelrh...@gmail.com> wrote: >>>>>> >>>>>>> Hi Luca, >>>>>>> >>>>>>> Here is my current setup: >>>>>>> >>>>>>> - OrientDB 2.1.1 (Single Server) >>>>>>> - Using Remote >>>>>>> - SQL using OCommand >>>>>>> - Stress test attempts about 3000 requests (individual user >>>>>>> requests) over 90 seconds >>>>>>> >>>>>>> The essence of the operation is as follows: >>>>>>> >>>>>>> Vertex Classes: Player, Location >>>>>>> Edge Classes: PresentIn, VisibleTo >>>>>>> >>>>>>> We have a player vertex "Luca" and a location vertex "New York". New >>>>>>> York has thousands of "PresentIn" edges connecting it to "Player" >>>>>>> vertices. >>>>>>> >>>>>>> The goal is to first retrieve a subset (5) of those Player vertices, >>>>>>> and then connect them to "Luca" with "VisibleTo" edges (Player -> >>>>>>> VisibleTo >>>>>>> -> Player). >>>>>>> >>>>>>> This is where it gets tricky: we only want player vertices that have >>>>>>> less than 5 "VisibleTo". Suffice to say, I found a way to avoid >>>>>>> contention >>>>>>> by first updating the records I want to reserve them. The query works, >>>>>>> and >>>>>>> is very fast since I started using lightweight edges. This way I was >>>>>>> able >>>>>>> to avoid contention for the same vertices and conflicts (I use >>>>>>> auto-merge >>>>>>> anyway). >>>>>>> >>>>>>> Now that i have 5 player vertices that are also connected to New >>>>>>> York and that nobody else can grab: I try to create "VisibleTo" edges >>>>>>> between "Luca" and them. This is where things go downhill -- the db just >>>>>>> seems to queue up until the requests timeout. If I do everything else, >>>>>>> but >>>>>>> comment out the edge creation, it's lightning fast. As soon as I tell >>>>>>> it to >>>>>>> create edges (as part of a transaction) it slows to a crawl. Note again >>>>>>> that these vertices have been reserved and excluded from selection by >>>>>>> concurrent requests -- so there shouldn't be contention. >>>>>>> >>>>>>> Any thoughts? I can provide more information if need be, but this >>>>>>> seems like a pretty major concern since edge creation at scale is a >>>>>>> fundamental operation. >>>>>>> >>>>>>> Thanks again guys! >>>>>>> >>>>>>> >>>>>>> On Tuesday, December 15, 2015 at 12:20:48 AM UTC-5, l.garulli wrote: >>>>>>>> >>>>>>>> Are you using it as single server or distributed? Is the client >>>>>>>> connected via remote protocol or plocal? Are you using plain SQL or >>>>>>>> Java >>>>>>>> API? >>>>>>>> >>>>>>>> Please provide more information about how you use OrientDB. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Luca Garulli >>>>>>>> Founder & CEO >>>>>>>> OrientDB <http://orientdb.com/> >>>>>>>> >>>>>>>> >>>>>>>> On 11 December 2015 at 22:12, nightrise <aelrh...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Great to hear. So I've upgraded from 2.1.1 to 2.1.7, and set the >>>>>>>>> consistency to notx_async_repair in the orient-server-config.xml. >>>>>>>>> >>>>>>>>> When I re-ran the same tests I saw substantial improvements in the >>>>>>>>> performance of edge creation -- but I see these benefits in >>>>>>>>> transaction as >>>>>>>>> well. I'm guessing perhaps there were other improvements in prior >>>>>>>>> releases? >>>>>>>>> >>>>>>>>> Sadly its still not really fast enough to be called truly >>>>>>>>> scalable. At 3000 requests over 90 seconds, I'm seeing substantial >>>>>>>>> queuing. >>>>>>>>> >>>>>>>>> Maybe there's something I'm missing here? Is there a performance >>>>>>>>> difference between notx_async_repair and notx_sync_repair? Should I >>>>>>>>> not set >>>>>>>>> the default conflict strategy to automerge for the affected class? >>>>>>>>> What >>>>>>>>> really are the optimal settings to deal with edge creation? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Friday, December 11, 2015 at 3:35:27 PM UTC-5, l.garulli wrote: >>>>>>>>>> >>>>>>>>>> If you work remote yes, it's outside, but with plocal it's in the >>>>>>>>>> same tx scope. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Luca Garulli >>>>>>>>>> Founder & CEO >>>>>>>>>> OrientDB <http://orientdb.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11 December 2015 at 20:13, nightrise <aelrh...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Another question for you Luca: >>>>>>>>>>> >>>>>>>>>>> If you're in a transaction, but execute a db.command with a >>>>>>>>>>> CREATE EDGE, this normally executes outside of the scope of the >>>>>>>>>>> transaction. Does this mean it will benefit from the improvements? >>>>>>>>>>> >>>>>>>>>>> On Wednesday, December 9, 2015 at 2:47:10 PM UTC-5, l.garulli >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> This improvement speeds up only non-tx mode. >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> >>>>>>>>>>>> Luca Garulli >>>>>>>>>>>> Founder & CEO >>>>>>>>>>>> OrientDB <http://orientdb.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9 December 2015 at 19:58, nightrise <aelrh...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Luca, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the update! Question about this new change: is edge >>>>>>>>>>>>> creation faster even in the default (transactional) mode as well, >>>>>>>>>>>>> or only >>>>>>>>>>>>> in the new modes? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tuesday, December 8, 2015 at 3:30:09 PM UTC-5, l.garulli >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>> >>>>>>>>>>>>>> We've just released #OrientDB v2.1.7 with new Graph >>>>>>>>>>>>>> Consistency to speed up edge creation: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://orientdb.com/docs/last/Graph-Consistency.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now you can execute CREATE EDGE outside transaction scope >>>>>>>>>>>>>> still having consistency on graph. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Luca Garulli >>>>>>>>>>>>>> Founder & CEO >>>>>>>>>>>>>> OrientDB <http://orientdb.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> 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 orient-databa...@googlegroups.com. >>>>>>>>>>>>> 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 orient-databa...@googlegroups.com. >>>>>>>>>>> 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 orient-databa...@googlegroups.com. >>>>>>>>> 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 orient-databa...@googlegroups.com. >>>>>>> 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 orient-databa...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> >>> Best regards, >>>> Andrey Lomakin, R&D lead. >>>> OrientDB Ltd >>>> >>>> twitter:@Andrey_Lomakin linkedin: >>>> https://ua.linkedin.com/in/andreylomakin >>>> >>> -- >>> >>> --- >>> 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 orient-databa...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> Best regards, >> Andrey Lomakin, R&D lead. >> OrientDB Ltd >> >> twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin >> > -- > > --- > 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 orient-database+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Best regards, Andrey Lomakin, R&D lead. OrientDB Ltd twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin -- --- 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
