You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2015/09/14 11:03:53 UTC
Nashorm Javascript engine
I can understand why one might want to enable the use of the Nashorn
JS engine, however I think it should have been discussed first.
The Nashorn engine is twice as slow as Rhino initially, so benefits
will only appear over the long run.
So there are potential drawbacks to making Nashorn the default.
Also it looks like the Google V8 engine is much better than Nashorn
(though maybe we cannot use it).
Furthermore, I don't understand why the change should only affect the
If Controller.
Rhino is also used by the _javascript function.
[The BSF and JSR223 elements also support Javascript, but that is a
separate issue entirely]
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
>>>>
>>>> On 14 September 2015 at 21:28, Philippe Mouawad
>>>>> <ph...@gmail.com> wrote:
>>>>>
>>>>>> On Mon, Sep 14, 2015 at 4:51 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>> On 14 September 2015 at 12:58, Vladimir Sitnikov
>>>>>>> <si...@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.
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
>>>
>>> On 14 September 2015 at 21:28, Philippe Mouawad
>>>> <ph...@gmail.com> wrote:
>>>>
>>>>> On Mon, Sep 14, 2015 at 4:51 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>> On 14 September 2015 at 12:58, Vladimir Sitnikov
>>>>>> <si...@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.
Re: Nashorm Javascript engine
Posted by Felix Schumacher <fe...@internetallee.de>.
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 <se...@gmail.com> wrote:
>>
>>> On 14 September 2015 at 21:28, Philippe Mouawad
>>> <ph...@gmail.com> wrote:
>>>> On Mon, Sep 14, 2015 at 4:51 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 14 September 2015 at 12:58, Vladimir Sitnikov
>>>>> <si...@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.
>>
>>
>>
>>
>
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
@Other team members, what's your opinion on this ?
Thanks
Regards
On Tue, Sep 15, 2015 at 7:38 AM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
>
>
> On Tuesday, September 15, 2015, sebb <se...@gmail.com> wrote:
>
>> On 14 September 2015 at 21:28, Philippe Mouawad
>> <ph...@gmail.com> wrote:
>> > On Mon, Sep 14, 2015 at 4:51 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 14 September 2015 at 12:58, Vladimir Sitnikov
>> >> <si...@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.
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tuesday, September 15, 2015, sebb <se...@gmail.com> wrote:
> On 14 September 2015 at 21:28, Philippe Mouawad
> <philippe.mouawad@gmail.com <javascript:;>> wrote:
> > On Mon, Sep 14, 2015 at 4:51 PM, sebb <sebbaz@gmail.com <javascript:;>>
> wrote:
> >
> >> On 14 September 2015 at 12:58, Vladimir Sitnikov
> >> <sitnikov.vladimir@gmail.com <javascript:;>> 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.
Re: Nashorm Javascript engine
Posted by sebb <se...@gmail.com>.
On 14 September 2015 at 21:28, Philippe Mouawad
<ph...@gmail.com> wrote:
> On Mon, Sep 14, 2015 at 4:51 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 September 2015 at 12:58, Vladimir Sitnikov
>> <si...@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.
> Complexity of such script would be very low.
Probably, but that does not mean the script cannot break.
> 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.
> 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.
>
>> >> 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.
> 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.
However if they selected "javascript" or "js" then they will get the
default JS engine.
> 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.
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
On Mon, Sep 14, 2015 at 4:51 PM, sebb <se...@gmail.com> wrote:
> On 14 September 2015 at 12:58, Vladimir Sitnikov
> <si...@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 ?
Complexity of such script would be very low.
I doubt Rhino and Nashorn would differ in the way of interpreting those
scripts.
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..
> >> 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.
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.
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.
In my opinion there are much bigger chances to break things here as the
script has chances to be bigger.
>
> 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.
Re: Nashorm Javascript engine
Posted by sebb <se...@gmail.com>.
On 14 September 2015 at 12:58, Vladimir Sitnikov
<si...@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.
>> 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
- it may have compatibility issues
it is clearly NOT OK to change JMeter without prior discussion of the issues.
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
Re: Nashorm Javascript engine
Posted by Vladimir Sitnikov <si...@gmail.com>.
> 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.
> 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]
>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?
[1] http://openjdk.java.net/projects/code-tools/jmh/
Vladimir
Re: Nashorm Javascript engine
Posted by sebb <se...@gmail.com>.
On 14 September 2015 at 10:42, Vladimir Sitnikov
<si...@gmail.com> wrote:
> Just my 2c: Nashorn is the default javascript implementation since
> Java 8, so if users try just "JSR223", they'll have to use different
> syntax between "if controller" and "JSR223".
>
> As far as I can see, JMeter does not bundle "rhino-223 wrapper", thus
As I already wrote, JSR223 is a separate issue, which we should
perhaps address in a separate thread.
> userы have no easy option to "stick with Rhino".
Rhino will continue to be available via the BSF test elements.
And we have control over JMeter's use of Rhino.
>>The Nashorn engine is twice as slow as Rhino initially,
>
> Any references?
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
> PS. The only case for using Rhino I see is "backward compatibility
> with old JMeter scripts when using Java 8".
Apart from compatibility issues [1], Nashorn is NOT always faster than Rhino.
Which is why I think the changes should have been discussed first.
[1] https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide
> Vladimir
Re: Nashorm Javascript engine
Posted by Vladimir Sitnikov <si...@gmail.com>.
Just my 2c: Nashorn is the default javascript implementation since
Java 8, so if users try just "JSR223", they'll have to use different
syntax between "if controller" and "JSR223".
As far as I can see, JMeter does not bundle "rhino-223 wrapper", thus
userы have no easy option to "stick with Rhino".
>The Nashorn engine is twice as slow as Rhino initially,
Any references?
PS. The only case for using Rhino I see is "backward compatibility
with old JMeter scripts when using Java 8".
Vladimir
Re: Nashorm Javascript engine
Posted by sebb <se...@gmail.com>.
On 14 September 2015 at 11:57, Philippe Mouawad
<ph...@gmail.com> wrote:
> On Mon, Sep 14, 2015 at 12:56 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 14, 2015 at 11:03 AM, sebb <se...@gmail.com> wrote:
>>
>>> I can understand why one might want to enable the use of the Nashorn
>>> JS engine, however I think it should have been discussed first.
>>>
>>
>> I thought it was discussed within
>>
>
>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57576
However that did not actually come to any conclusion.
>>
>>>
>>> The Nashorn engine is twice as slow as Rhino initially, so benefits
>>> will only appear over the long run.
>>>
>> From the bench I made using 2 IfController , 50 Threads and 100
>> Iterations, Throughtput of current JMeter Nashorn integration is higher
>> than Rhino's one. I didn't compare strictly the 2 engines.
>> I will attach my test plan but I let you make some tests.
>>
>>
>>> So there are potential drawbacks to making Nashorn the default.
>>>
>> Which ones if we exclude the "performance", knowing we introduced an
>> option to revert to it and also added a mention in Breaking Changes ?
>> For performances I don't read results as you do, in my understanding once
>> Nashorn is warm it's much faster than rhino.
>>
>>>
>>> Also it looks like the Google V8 engine is much better than Nashorn
>>> (though maybe we cannot use it).
>>>
>>> Furthermore, I don't understand why the change should only affect the
>>> If Controller.
>>>
>>
>>
>> I updated IfController because I was looking for a first step to improve
>> performances of Javascript part.
>> And I must say I never use the Javascript function due to performances
>> compared to Groovy code.
>> By the way (I will open another subject), as Groovy is becoming an Apache
>> project, how about embedding it in JMeter ? So that it's here as a
>> replacement to Beanshell ?
>>
>> Rhino is also used by the _javascript function.
>>>
>> You're right function should also be updated.
>>
>>>
>>> [The BSF and JSR223 elements also support Javascript, but that is a
>>> separate issue entirely]
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
On Mon, Sep 14, 2015 at 12:56 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
>
>
> On Mon, Sep 14, 2015 at 11:03 AM, sebb <se...@gmail.com> wrote:
>
>> I can understand why one might want to enable the use of the Nashorn
>> JS engine, however I think it should have been discussed first.
>>
>
> I thought it was discussed within
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57576
>
>>
>> The Nashorn engine is twice as slow as Rhino initially, so benefits
>> will only appear over the long run.
>>
> From the bench I made using 2 IfController , 50 Threads and 100
> Iterations, Throughtput of current JMeter Nashorn integration is higher
> than Rhino's one. I didn't compare strictly the 2 engines.
> I will attach my test plan but I let you make some tests.
>
>
>> So there are potential drawbacks to making Nashorn the default.
>>
> Which ones if we exclude the "performance", knowing we introduced an
> option to revert to it and also added a mention in Breaking Changes ?
> For performances I don't read results as you do, in my understanding once
> Nashorn is warm it's much faster than rhino.
>
>>
>> Also it looks like the Google V8 engine is much better than Nashorn
>> (though maybe we cannot use it).
>>
>> Furthermore, I don't understand why the change should only affect the
>> If Controller.
>>
>
>
> I updated IfController because I was looking for a first step to improve
> performances of Javascript part.
> And I must say I never use the Javascript function due to performances
> compared to Groovy code.
> By the way (I will open another subject), as Groovy is becoming an Apache
> project, how about embedding it in JMeter ? So that it's here as a
> replacement to Beanshell ?
>
> Rhino is also used by the _javascript function.
>>
> You're right function should also be updated.
>
>>
>> [The BSF and JSR223 elements also support Javascript, but that is a
>> separate issue entirely]
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Nashorm Javascript engine
Posted by Philippe Mouawad <ph...@gmail.com>.
On Mon, Sep 14, 2015 at 11:03 AM, sebb <se...@gmail.com> wrote:
> I can understand why one might want to enable the use of the Nashorn
> JS engine, however I think it should have been discussed first.
>
I thought it was discussed within
>
> The Nashorn engine is twice as slow as Rhino initially, so benefits
> will only appear over the long run.
>
>From the bench I made using 2 IfController , 50 Threads and 100 Iterations,
Throughtput of current JMeter Nashorn integration is higher than Rhino's
one. I didn't compare strictly the 2 engines.
I will attach my test plan but I let you make some tests.
> So there are potential drawbacks to making Nashorn the default.
>
Which ones if we exclude the "performance", knowing we introduced an option
to revert to it and also added a mention in Breaking Changes ?
For performances I don't read results as you do, in my understanding once
Nashorn is warm it's much faster than rhino.
>
> Also it looks like the Google V8 engine is much better than Nashorn
> (though maybe we cannot use it).
>
> Furthermore, I don't understand why the change should only affect the
> If Controller.
>
I updated IfController because I was looking for a first step to improve
performances of Javascript part.
And I must say I never use the Javascript function due to performances
compared to Groovy code.
By the way (I will open another subject), as Groovy is becoming an Apache
project, how about embedding it in JMeter ? So that it's here as a
replacement to Beanshell ?
Rhino is also used by the _javascript function.
>
You're right function should also be updated.
>
> [The BSF and JSR223 elements also support Javascript, but that is a
> separate issue entirely]
>
--
Cordialement.
Philippe Mouawad.