I created issue for it https://github.com/orientechnologies/orientdb/issues/5566
Thx W dniu środa, 6 stycznia 2016 11:24:24 UTC+1 użytkownik Andrey Lomakin napisał: > > Hi Pawel, > > We do not have time right now but maybe you will create issue and we will > look at it ? > > On Mon, Dec 28, 2015 at 7:17 PM Pawel K. <[email protected] <javascript:>> > wrote: > >> Hi machak, >> >> well... actually the test is taken from OrientDB's unit tests source code >> only with my simple time measurement which could probably be done better. >> My intention was to provide guys who wrote the system known piece of code >> showing the same behaviour. >> Sleep parts what you are referring to, are not part of discussed problem >> but rather related to optimistic versioning retries. This code is not >> invoked in the test. I am talking about concurrentPessimisticSQLUpdates >> (). >> >> >> W dniu poniedziałek, 28 grudnia 2015 06:45:32 UTC+1 użytkownik machak >> napisał: >>> >>> looking at your testcase I really feel like a moron and asking myself >>> what are you actually measuring...there are thread sleeps in there, >>> like Thread.sleep(retries * 10) so, in case of "retries" part is very >>> high, you end up blocking forever... >>> could you just simplify stuff and maybe use proper micro benchmark like >>> JMH (http://openjdk.java.net/projects/code-tools/jmh/), >>> my 2 cents >>> cheers >>> /m >>> >>> On Sunday, December 27, 2015 at 11:46:10 PM UTC+1, Pawel K. wrote: >>>> >>>> Hi Andrey, >>>> First of all, my bad. I made one mistake in my benchmark which affected >>>> the results. So it's not that bad! >>>> I also found >>>> that ConcurrentUpdatesTest.concurrentPessimisticSQLUpdates() test case is >>>> very similar to my case. >>>> I slightly modified it adding opsrate/sec. Available here >>>> https://gist.github.com/anonymous/305d33338c9f94c12b55 >>>> >>>> Based on it I have following results: >>>> >>>> v2.1.8 >>>> ConcurrentUpdatesTest.concurrentPessimisticSQLUpdates() >>>> private final static int PESSIMISTIC_CYCLES = 10000; >>>> private final static int THREADS = 12; >>>> Elapsed time [ms]:79284 >>>> Rate ops/sec:1513 >>>> >>>> >>>> v2.0.16 >>>> ConcurrentUpdatesTest.concurrentPessimisticSQLUpdates() >>>> private final static int PESSIMISTIC_CYCLES = 10000; >>>> private final static int THREADS = 12; >>>> Elapsed time [ms]:23581 >>>> Rate ops/sec:5088 >>>> >>>> >>>> v2.0.8 >>>> ConcurrentUpdatesTest.concurrentPessimisticSQLUpdates() >>>> private final static int PESSIMISTIC_CYCLES = 10000; >>>> private final static int THREADS = 12; >>>> Elapsed time [ms]:17488 >>>> Rate ops/sec:6861 >>>> >>>> >>>> Any clue why it is getting slower and slower with each next version? >>>> Can you or someone confirm similar results? >>>> >>>> >>>> >>>> >>>> W dniu piątek, 25 grudnia 2015 19:19:44 UTC+1 użytkownik Pawel K. >>>> napisał: >>>>> >>>>> No CME, it's just slower .In that case I rely on pessimistic locking. >>>>> Imo the lock is broader/longer? >>>>> Pawel >>>>> >>>>> >>>>> >>>>> W dniu piątek, 25 grudnia 2015 13:08:37 UTC+1 użytkownik Andrey >>>>> Lomakin napisał: >>>>>> >>>>>> Hi Pawel, >>>>>> Just to make things clear. >>>>>> >>>>>> Do you receive any concurrent modification exceptions or locks merely >>>>>> become slower ? >>>>>> >>>>>> On Thu, Dec 24, 2015 at 12:17 AM Pawel K. <[email protected]> wrote: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I use OrientDB version 2.0.x. I wanted to migrate to 2.1.x (2.1.8) >>>>>>> After running my internal tests in .NET I realized that the >>>>>>> performance of sql UPDATE operation is really dramatic. >>>>>>> >>>>>>> One of my test invokes really basic sql operation with pessimistic >>>>>>> locking >>>>>>> >>>>>>> UPDATE #13:0 INCREMENT Salary = 1 LOCK RECORD >>>>>>> >>>>>>> in 8-12 threads. >>>>>>> >>>>>>> Orientdb v2.0.16 delivers nice performance on desktop machine >>>>>>> >>>>>>> Rate 8810,57268722467/sec, 10000 objects took 1135ms Threads=8 >>>>>>> Rate 9033,42366757001/sec, 10000 objects took 1107ms Threads=9 >>>>>>> Rate 8976,66068222621/sec, 10000 objects took 1114ms Threads=9 >>>>>>> >>>>>>> wheras v2.1.x >>>>>>> >>>>>>> >>>>>>> ~ 150 ops/sec which basically kills my app. >>>>>>> >>>>>>> Any thoughts? >>>>>>> >>>>>>> Pawel >>>>>>> >>>>>>> PS. All ALTER/CREATE operations are sooo long now, that all my tests >>>>>>> got 10x more time to execute. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> 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. >>>>>>> >>>>>> -- >>>>>> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
