You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
parallel/test-tls-server-verify is awfully slow on Windows #1461
I think the cause for the long runtime is in OpenSSL. The s_client on windows generates extra entropy by loading screen memory and this takes ~1-2s on each spawn. I don't get why they are not using something like windows CryptGenRandom() function but I'm no openssl or even crypto expert so correct me if I am wrong.
@mathiask88 The test has always been slow for me, but I never got any further than figuring out that the openssl command-line client is really slow. Thanks for digging this up.
@jbergstroem Yes and I think it is not necessary. The client runs app_RAND_load_file() that returns on windows something like C:\.rnd and tries to read that entropy file. If this fails RAND_status() gets called and if this is called for the first time openssl gets initialized with RAND_poll() and that function calls CryptGetRandom() on Windows NT+ or Windows CE 3.0+ anyway. So I think RAND_screen() is a relict where OpenSSL didn't use an OS-based seed initialization.
But I tested a bit more and it seems that the screen loading is not the bottleneck here. It doesn't take ~1s as I thought. If I run a server like in the test and then a *.bat file with echo QUIT | openssl-cli.exe s_client -connect 127.0.0.1:12346 the openssl-cli takes about 2s to exit after _(un)authed.
Now working on a workaround, modifying the test to let all those test cases run in parallel instead of serialized, so that it finishes quickly in spite of the openssl-cli delay.
We will submit the change to io.js as well as Node.
Do you folks mind reviewing the change here: nodejs/node-v0.x-archive#25368, to make sure we have a consistent +1? I can then cherry pick the commits to io.js in another PR. Thanks!
I looked at this and found that we can have one more improvement to use child.kill() not to wait for child processes to be ended. shigeki@ad45f88
RAND_screen() on my Windows takes more than one second. I think we need not to have a good client randomness in this test. Adding a -no-rand-screen option for openssl s_client on Windows is one of ideas to remove this overhead. shigeki@12be7ec and shigeki@dae36fb
Regarding using child.kill(), I wonder if this changes the test in way that could limit its effectiveness in catching bugs. But I will add shigeki@ad45f88 to the PR and let people who are more experienced in this area provide feedback.
Regarding, --no-rand-screen it sounds like a wonderful feature. But it would be a floating patch on a dependency, and I wonder if that would be appropriate here. In node we usually tend to limit those floating patches to changes that have already been made in the upstream project, or are high priority and at least have a clear path for being accepted upstream.
Activity
mathiask88 commentedon Apr 30, 2015
I think the cause for the long runtime is in OpenSSL. The
s_clienton windows generates extra entropy by loading screen memory and this takes ~1-2s on each spawn. I don't get why they are not using something like windowsCryptGenRandom()function but I'm no openssl or even crypto expert so correct me if I am wrong.jbergstroem commentedon May 12, 2015
@mathiask88 thanks for digging that up. Seems to have been around for a while.
trevnorris commentedon May 12, 2015
/cc @indutny @piscisaureus on using
CryptGetRandom()piscisaureus commentedon May 12, 2015
@mathiask88 The test has always been slow for me, but I never got any further than figuring out that the openssl command-line client is really slow. Thanks for digging this up.
mathiask88 commentedon May 13, 2015
@jbergstroem Yes and I think it is not necessary. The client runs
app_RAND_load_file()that returns on windows something likeC:\.rndand tries to read that entropy file. If this failsRAND_status()gets called and if this is called for the first time openssl gets initialized withRAND_poll()and that function callsCryptGetRandom()on Windows NT+ or Windows CE 3.0+ anyway. So I thinkRAND_screen()is a relict where OpenSSL didn't use an OS-based seed initialization.But I tested a bit more and it seems that the screen loading is not the bottleneck here. It doesn't take ~1s as I thought. If I run a server like in the test and then a *.bat file with
echo QUIT | openssl-cli.exe s_client -connect 127.0.0.1:12346the openssl-cli takes about 2s to exit after_(un)authed.orangemocha commentedon May 14, 2015
The test is slow on Windows because of two 1 second delays in the Windows version of openssl-cli.exe. We have reported the issue to openssl: http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3849
Now working on a workaround, modifying the test to let all those test cases run in parallel instead of serialized, so that it finishes quickly in spite of the openssl-cli delay.
We will submit the change to io.js as well as Node.
Fishrock123 commentedon May 14, 2015
Awesome, thanks!
orangemocha commentedon May 22, 2015
Do you folks mind reviewing the change here: nodejs/node-v0.x-archive#25368, to make sure we have a consistent +1? I can then cherry pick the commits to io.js in another PR. Thanks!
rvagg commentedon May 23, 2015
/cc @nodejs/crypto to @orangemocha's comment above, sounds positive to me but could do with a word of encouragement from someone in the crypto team
shigeki commentedon May 27, 2015
I looked at this and found that we can have one more improvement to use
child.kill()not to wait for child processes to be ended. shigeki@ad45f88RAND_screen() on my Windows takes more than one second. I think we need not to have a good client randomness in this test. Adding a -no-rand-screen option for openssl s_client on Windows is one of ideas to remove this overhead. shigeki@12be7ec and shigeki@dae36fb
The benchmark results are
9.5 seconds are still slow compared to Unix but it seems to be enough good for CI.
jbergstroem commentedon May 27, 2015
I'm all for
--no-rand-screen; this openssl binary isn't used for anything other than verifying our test suite.orangemocha commentedon May 27, 2015
Regarding using child.kill(), I wonder if this changes the test in way that could limit its effectiveness in catching bugs. But I will add shigeki@ad45f88 to the PR and let people who are more experienced in this area provide feedback.
Regarding,
--no-rand-screenit sounds like a wonderful feature. But it would be a floating patch on a dependency, and I wonder if that would be appropriate here. In node we usually tend to limit those floating patches to changes that have already been made in the upstream project, or are high priority and at least have a clear path for being accepted upstream.orangemocha commentedon May 27, 2015
Updated nodejs/node-v0.x-archive#25368
119 remaining items
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client
deps: add -no_rand_screen to openssl s_client