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]> 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]. > 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.
