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