Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nashorn execution performance cracking #121

Open
MrLi2018 opened this issue Oct 18, 2021 · 6 comments
Open

Nashorn execution performance cracking #121

MrLi2018 opened this issue Oct 18, 2021 · 6 comments
Labels

Comments

@MrLi2018
Copy link

MrLi2018 commented Oct 18, 2021

Background: I only set the CPU duration when executing scripts using nashorn, but I found that the value was long whenever the thread was nearing the end of the thread when executing with the thread pool.
phenomenon:
Listen to the following code:
` synchronized (monitor) {
long waitTime = getCheckInterval(runtime);

                    if (waitTime == 0) {
                        waitTime = 1;
                    }
                    long start=System.currentTimeMillis();
                    monitor.wait(waitTime);
                    LOGGER.info(" cost {}",System.currentTimeMillis()-start);
                }

result:15:31:48.702 [pool-2-thread-8] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 16
15:31:48.702 [pool-2-thread-7] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 16
15:31:48.702 [pool-2-thread-8] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 0
15:31:48.702 [pool-2-thread-2] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 0
15:31:48.702 [pool-2-thread-4] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 0
15:31:48.702 [pool-2-thread-3] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 0
15:31:50.473 [pool-2-thread-6] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 2006
15:31:50.473 [pool-2-thread-5] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 2006
15:31:50.474 [pool-2-thread-6] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 1
15:31:50.474 [pool-2-thread-5] [INFO] [delight.nashornsandbox.internal.ThreadMonitorTest.run(ThreadMonitorTest.java:139)] - cost 1`

Why Fluctuations Occur?

@obourgain
Copy link
Contributor

hello, please do not ping people just one hour after posting your issue

@MrLi2018
Copy link
Author

sorry!

@mxro
Copy link
Collaborator

mxro commented Oct 24, 2021

Hello @MrLi2018, thank you for posting this issue.

That is very intersting - so running the same script has a lot of variation in execution times. Maybe some further things to confirm/try:

  1. Try running the script with the new precompiled script feature and see if the variation persists:
NashornSandbox sandbox = NashornSandboxes.create();
CompiledScript script = sandbox.compile("1 + 1");
int result1 = (int) sandbox.eval(script);
int result2 = (int) sandbox.eval(script);
  1. Try running without an executor script or try different types of thread pools
sandbox.setExecutor(Executors.newSingleThreadExecutor());
  1. Ensure there are no other processes running on the JVM/machine.

  2. Try running the original script or the script generated by the sandbox using vanialla Nashorn. You can see the script generated using log4j.logger.delight.nashornsandbox.NashornSandbox=DEBUG

Hope this helps!

@mxro mxro added the question label Oct 24, 2021
@MrLi2018
Copy link
Author

MrLi2018 commented Dec 13, 2021 via email

@MrLi2018
Copy link
Author

MrLi2018 commented Dec 13, 2021 via email

@mxro
Copy link
Collaborator

mxro commented Dec 14, 2021

Thank you for your reply. Happy to try and help get to the bottom of this!

The execution time of individual scripts is always near the execution time of the CPU I set.

Are you saying that no matter the compleixty of the script, the execution time is always near the limit? That has not been my experience and there are a number of unit tests in this repo that I think show otherwise. Maybe you could construct a test case demonstrating this? The consumed CPU time should scale up with the complexity of the script.

This result will occur even if a very simple script runs many times

And here are you saying that the CPU time accumulates across script executions. Had a quick look into the code, and I think for every eval that should reset. But maybe I'm missing something. If you can spot the issue in the code or a test case, please let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants