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]. For more options, visit https://groups.google.com/d/optout.
