423 disable js engine #424
Conversation
|
cool |
Co-authored-by: h-arlt <h.arlt@xceptance.de>
Co-authored-by: h-arlt <h.arlt@xceptance.de>
There was a problem hiding this comment.
XltWebClient always sets an XltJavaScriptEngine instance at the moment. To save even more resources, this should be skipped if javaScriptEngineEnabled is false.
When loading static content, the XltWebClient relies on the Javascript engine being available in order to evaluate CSS styles, etc. This functionality of XltWebClient needs to be bypassed when javaScriptEngineEnabled is false.
Also it seems that we should rather replace most occurrences of WebClient.getOptions().isJavaScriptEnabled() with WebClient.isJavaScriptEnabled() as the latter also takes the javaScriptEngineEnabled flag into account.
This is something still on my list - maybe i can give it another try to finally fix this
Sounds correct for me |
I guess this is now fixed. Do you have some time to test this? |
|
just made a new snapshot build... |
…y on JavaScript support
…o when JS is off * first XltWebClient tweaks
* adjusted various test cases to enable JS engine/JS where needed
| // check all style sheets | ||
| final StyleSheetList sheets = document.getStyleSheets(); | ||
| for (int i = 0; i < sheets.getLength(); i++) | ||
| if (isJavaScriptEnabled()) |
There was a problem hiding this comment.
with 3.7 js support is no longer required to work with style sheets.
At least for this you can hopefully use HtmlPage.getStyleSheets() HtmlUnit/htmlunit@03877bb.
Will try to make a new snapshot later today.
There was a problem hiding this comment.
Cool! When time permits, we will upgrade to 3.7 and see what we can simplify on our end.
JS engine is off by default and not started. A short test has shown that the scripts for regular load tests still work. We are also not creating the debugger object, if not needed.
CPU
-10 %
Old
New
Memory
-200 MB
Old
New