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 Wed, 16 Sep 2015 20:24:35 GMT
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.

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