Just to be sure though, what if you make a quick change to your SSLeay.xs to verify that the problem is in SSL_read...
PREINIT: char *buf; int got; int succeeded = 1; struct timespec ts1, ts2; long dT; PPCODE: New(0, buf, max, char); clock_gettime(CLOCK_MONOTONIC, &ts1); got = SSL_read(s, buf, max); clock_gettime(CLOCK_MONOTONIC, &ts2); dT= (ts2.tv_nsec - ts1.tv_nsec)/1000 + (ts2.tv_sec - ts1.tv_sec)*1000000; warn("SSL_read(s, buf, %ld) => %ld (%ld us)\n", (long)max, (long)got, dT); if (got <= 0 && SSL_ERROR_ZERO_RETURN != SSL_get_error(s, got) +) succeeded = 0;
This probably only works on Linux (haven't checked if MSWin32 added clock_gettime yet) and if you aren't able to test, let me know and I will.
It will also completely throw off the CPU usage report because now it prints on every read, but it should still be able to measure the duration of the SSL_read calls. (the other option is to capture the timings in a persistent buffer and print them at the end, but that's a lot of hassle.)
If the timing of SSL_read matches your results above, then it would be time to head to the openssl project with a bug report. But, if it doesn't, then maybe the slowness is inside SSL_get_error or something else in the surrounding code that only happens on an unproductive read.
And the other option is to build against a debug-symbols version of libssl, and go all the way down into it with gdb.
In reply to Re^5: IO::Socket::SSL / Net::SSLeay inefficient in non-blocking mode ?
by NERDVANA
in thread IO::Socket::SSL / Net::SSLeay inefficient in non-blocking mode ?
by Yaribz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |