groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serega Sheypak <serega.shey...@gmail.com>
Subject Re: Optimizing groovy performace
Date Sun, 17 Apr 2016 12:36:56 GMT
ok, I see weird results.
I've wrote a test
https://gist.github.com/seregasheypak/d59997dd2d2dfbf82e310b16398239ca

Here are metrics for method named "play"

TriggerPlayer.play-trigger

             count = 83043

         mean rate = 395.52 calls/second

     1-minute rate = 555.30 calls/second

     5-minute rate = 217.78 calls/second

    15-minute rate = 82.92 calls/second

               min = 0.29 milliseconds

               max = 12.98 milliseconds

              mean = 1.59 milliseconds

            stddev = 1.08 milliseconds

            median = 1.39 milliseconds

              75% <= 2.46 milliseconds

              95% <= 3.14 milliseconds

              98% <= 3.44 milliseconds

              99% <= 3.76 milliseconds

            99.9% <= 12.19 milliseconds


Here are metrics for method named "executeHere"

    count = 81927

         mean rate = 503.31 calls/second

     1-minute rate = 587.41 calls/second

     5-minute rate = 221.08 calls/second

    15-minute rate = 83.42 calls/second

               min = 0.06 milliseconds

               max = 0.47 milliseconds

              mean = 0.08 milliseconds

            stddev = 0.03 milliseconds

            median = 0.08 milliseconds

              75% <= 0.09 milliseconds

              95% <= 0.13 milliseconds

              98% <= 0.16 milliseconds

              99% <= 0.17 milliseconds

            99.9% <= 0.44 milliseconds


"executeHere" faster in 40 times (acrroding to 99th percentile).

I just copy-pasted body of method directly to test...

What does it mean, why it works faster?

2016-04-16 21:52 GMT+02:00 Serega Sheypak <serega.sheypak@gmail.com>:

> > Firstly sorry for not answering so fast. I have not so much spare time
> these days :( And your question requires some thought
> No problem, I really happy to get any input from community members side.
> if I now assume this will start 1000 threads, each with its own cache,
> then you get 20k compilations,
> It goes a bit different way. I'll explain how does my installation works.
> Storm starts 4 JVM per node. Each JVM has 5 threads to run my code.
> Each thread has it's own script factory.
> Thread that runs code lives forever (until you kill it or apocalypses
> happens. Storm can restart thread in case of failure)
>
> > Doing all that unreflection in the indy part and creating those
> MethodHandles always takes a little time.
> It happens only right, correct?
> I don't have thousands of threads. There are dozens of them.
>
> >Is it somehow possible to get a small running program showing the
> problem?
> Hm... I'll try to extract it.
>
> 2016-04-16 13:27 GMT+02:00 Jochen Theodorou <blackdrag@gmx.org>:
>
>> Firstly sorry for not answering so fast. I have not so much spare time
>> these days :( And your question requires some thought
>>
>> On 11.04.2016 12:58, Serega Sheypak wrote:
>> [...]
>>
>>> *>do you reuse the scripts, or do you make a new script each time?*
>>> I suppose I do reuse, please have a look at "ScriptFactory"
>>>
>>> *Hi, here is naive caching factory:*
>>> https://gist.github.com/seregasheypak/2d7f5a16fa31018c8212754c8e94f9a4
>>>
>>> *>To give an advice I have to understand your setup better first*
>>> I run http://storm.apache.org/ topology.
>>> If you are not familiar with it, assume I have a running thread-safe
>>> java application. Java application keeps 1000 User objects and 20
>>> GroovyScripts in memory.
>>> I run 1000 (users) *20 (script: def evaluateExpression(Map context))
>>> executions each second.
>>> If script for User object returns true, I do something special.
>>>
>>> I try to cache script instances (see my gist).
>>> User object is just a bean with some logic incapsulated.
>>>
>>
>> if I now assume this will start 1000 threads, each with its own cache,
>> then you get 20k compilations, as well as 20k first time executions. Doing
>> all that unreflection in the indy part and creating those MethodHandles
>> always takes a little time. So it might very well be, that this is the
>> problem, but not sure what we could do then.
>>
>> Is it somehow possible to get a small running program showing the
>> problem? Then I could check myseld what really happens. JVisualVM helps a
>> bit, but is imho no proper replacement for a real profiler.
>>
>> bye Jochen
>>
>>
>

Mime
View raw message