jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Nashorm Javascript engine
Date Sat, 03 Oct 2015 20:36:31 GMT
Hello,
I commited Felix consensus :-) proposal :
- Renamed property to javascript.use_rhino=true , if switched to false
Nashorn is used if available
- Rhino stays the default engine
Concerned bugzilla:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58406

As per sebb note, I also added  Nashorn to __javaScript function within:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58477

A test I made using 3 javascript functions under Java8, 50 Threads running
for 60 seconds with 30s startup delay.:
NASHORN:
Summary Results =  71378 in  90,1s =  792,0/s Avg:     0 Min:     0 Max:
84 Err:     0 (0,00%)

RHINO:
Summary Results =  45855 in  90,2s =  508,6/s Avg:     0 Min:     0 Max:
14 Err:     0 (0,00%)


So within this test, we have a throughput improvement of 56%.
Regards
Philippe M.
@philmdot



On Wed, Sep 16, 2015 at 10:24 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

> Thanks Felix,
> Looks ok for me.
>
> What's your opinion on javascript function, should we follow the same
> strategy ?
>
> Thanks
>
>
> On Wednesday, September 16, 2015, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Am 15.09.2015 um 21:40 schrieb Philippe Mouawad:
>>
>>> Hello,
>>> @Other team members, what's your opinion on this ?
>>>
>> We shouldn't give up backward compatibility lightly.
>>
>> In case of the javascript interpreter, that comes with the jvm, I think
>> it is ok, to use the default interpreter of the jvm. The differences, that
>> were shown in the migration guide were not the ones, I would expect in
>> small scripts as they are probably found in the ifcontroller.
>>
>> But I would expect to have the same javascript environment in all places.
>>
>> Since the current stable version uses rhino, it could be a good strategy
>> to enable the use of nashorn, but leave rhino the default. Make a big note,
>> that we will switch to prefer nashorn in some near future, so that people
>> have a chance to test it and report problems. When no problems are
>> reported, we can switch to nashorn.
>>
>> Regards,
>>  Felix
>>
>>
>>> Thanks
>>> Regards
>>>
>>> On Tue, Sep 15, 2015 at 7:38 AM, Philippe Mouawad <
>>> philippe.mouawad@gmail.com> wrote:
>>>
>>>
>>>> On Tuesday, September 15, 2015, sebb <sebbaz@gmail.com> wrote:
>>>>
>>>> On 14 September 2015 at 21:28, Philippe Mouawad
>>>>> <philippe.mouawad@gmail.com> wrote:
>>>>>
>>>>>> On Mon, Sep 14, 2015 at 4:51 PM, sebb <sebbaz@gmail.com> wrote:
>>>>>>
>>>>>> On 14 September 2015 at 12:58, Vladimir Sitnikov
>>>>>>> <sitnikov.vladimir@gmail.com> wrote:
>>>>>>>
>>>>>>>> Apart from compatibility issues [1]
>>>>>>>>>
>>>>>>>> I do know there are compatibility issues, however is is rather
>>>>>>>> smooth
>>>>>>>> if you are creating a new script.
>>>>>>>> I do know what "backward compatibility" is.
>>>>>>>>
>>>>>>> It means that existing Javascript scripts will run without needing
to
>>>>>>> be amended.
>>>>>>>
>>>>>>> What is the probability to break a Javascript code in IF Controller
?
>>>>>>
>>>>> Depends on what the incompatible changes are.
>>>>>
>>>>>   so what do you propose ?
>>>>> Complexity of such script would be very low.
>>>>>
>>>>> Probably, but that does not mean the script cannot break.
>>>>>
>>>>>
>>>>> so you want the statu quo ?
>>>>
>>>>
>>>> I doubt  Rhino and Nashorn would differ in the way of interpreting those
>>>>>> scripts.
>>>>>>
>>>>> That may be true but is just guesswork without more evidence.
>>>>>
>>>>>
>>>>> I don't know what to say. I tend to think we have very low risk to have
>>>> issues here, we mention the incompatible change so user check their
>>>> script
>>>> once they upgrade.
>>>> And if any regression they have the option to debug or revert to old
>>>> behaviour.
>>>> Backward compatibility is rather well managed here. It should not be a
>>>> stopper for any change in JMeter.
>>>>
>>>> New scripts are built on nashorn and that 's it.
>>>>
>>>> You think something else, why would I have to prove that it will not
>>>> break
>>>> , and not you prove that it will?
>>>>
>>>>
>>>>
>>>> In my opinion unless you have a big explicit case where it breaks I see
>>>> no
>>>> reason not to move forward.
>>>>
>>>>
>>>>
>>>>
>>>> Based on this:
>>>>>> https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
>>>>>>
>>>>>> Maybe the biggest risk is in replace, but I am not sure..
>>>>>>
>>>>> This needs to be established.
>>>>>
>>>>>
>>>>> what do you propose ?
>>>>
>>>>
>>>> I got the speed info from the diagram in the link from the Bugzilla:
>>>>>>>>>
>>>>>>>>>
>>>>> http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html
>>>>>
>>>>>> This benchmark makes very little sense. Proper benchmarking should
>>>>>>>> involve jmh [1]
>>>>>>>>
>>>>>>> I quoted the URL because it was used in justifying Nashorn over
>>>>>>> Rhino.
>>>>>>> However the page clearly shows that Nashorn is not always faster.
>>>>>>>
>>>>>>> Given that
>>>>>>> - Nashorn is not always faster
>>>>>>>
>>>>>>> Can you point to a particular case where it is not and that users
>>>>>> would
>>>>>> meet in the JMeter scope ?
>>>>>>
>>>>>>
>>>>>> - it may have compatibility issues
>>>>>>>
>>>>>>> as long as we propose a way to select rhino and given that chances
of
>>>>>> having regressions is very low, is it really a big risk.
>>>>>>
>>>>> We don't yet what the chance of regressions is.
>>>>>
>>>>
>>>> the migration guide does not show big regression risks.
>>>>
>>>>
>>>> In the benchmark I made using 2 IfControllers, there is a 50% increase
>>>>>>
>>>>> in
>>>>>
>>>>>> throughput.
>>>>>>
>>>>>>
>>>>>> it is clearly NOT OK to change JMeter without prior discussion of
the
>>>>>>
>>>>>>> issues.
>>>>>>>
>>>>>>>
>>>>>> I suppose we are discussing it here.
>>>>>>
>>>>> Yes, we are now.
>>>>>
>>>>> One side note.
>>>>>> Whenever a user migrates to Java8, the Javascript engine used by
>>>>>> JSR223
>>>>>> Test Elements is switched without any other notice from RHINO to
>>>>>>
>>>>> NASHORN.
>>>>>
>>>>> That's not quite true.
>>>>>
>>>>> If the user originally selected "rhino" then the test plan will fail
>>>>> because "rhino" has been dropped as a valid engine.
>>>>>
>>>>>   As a standard user, would you choose javascript (very well known) or
>>>>>
>>>> rhino(more specialized ) ?
>>>> I think most users choose javascript.
>>>> Seeing lot of questions on JMeter at stackoverflow , they frequently
>>>> mention js or javascript.
>>>>
>>>>
>>>> However if they selected "javascript" or "js" then they will get the
>>>>
>>>>> default JS engine.
>>>>>
>>>> And in this case there are chances to break.
>>>>
>>>>
>>>> In my opinion there are much bigger chances to break things  here as the
>>>>>> script has chances to be bigger.
>>>>>>
>>>>> It is likely that such scripts will be bigger, however the user will
>>>>> get a clear warning if they selected Rhino specifically.
>>>>>
>>>>> We may well decide that the advantages outweigh the disadvantages, but
>>>>>>> that discussion needs to occur and for agreement to be reached.
>>>>>>>
>>>>>>> Nashorn is NOT always faster than Rhino
>>>>>>>>>
>>>>>>>> Well, what if it is faster in 99.9% cases?
>>>>>>>> I mean that we never find a library that will be always faster
than
>>>>>>>> Rhino. There always be at lease a case or two where Rhino
wins.
>>>>>>>> Does that mean we have to live with Rhino forever?
>>>>>>>>
>>>>>>> No, but the decision needs to take these facts into consideration.
>>>>>>>
>>>>>>> [1] http://openjdk.java.net/projects/code-tools/jmh/
>>>>>>>>
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cordialement.
>>>>>> Philippe Mouawad.
>>>>>>
>>>>>
>>>> --
>>>> Cordialement.
>>>> Philippe Mouawad.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message