jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Nashorm Javascript engine
Date Mon, 14 Sep 2015 10:56:53 GMT
On Mon, Sep 14, 2015 at 11:03 AM, sebb <> 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]

Philippe Mouawad.

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