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 < [email protected]> 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 < > [email protected]> 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 < >>> [email protected]> wrote: >>> >>> >>>> On Tuesday, September 15, 2015, sebb <[email protected]> wrote: >>>> >>>> On 14 September 2015 at 21:28, Philippe Mouawad >>>>> <[email protected]> wrote: >>>>> >>>>>> On Mon, Sep 14, 2015 at 4:51 PM, sebb <[email protected]> wrote: >>>>>> >>>>>> On 14 September 2015 at 12:58, Vladimir Sitnikov >>>>>>> <[email protected]> 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.
