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.
