> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Froehlich > > Ferdinand Prantl wrote: > > > Hello, > > > > I am sorry for the long post, there is a question at the > very end :-) > > (I sent it to the the openssl-users group at first, maybe you the > > developers are interested rather than users.) > > > > We integrate OpenSSL 0.9.6l compiled with standard settings > and linked > > statically on Win32 and used on Windows XP, 2000 and 2003. > > > > The initialization of OpenSSL used within an extension module for > > Microsoft Sharepoint 2003 caused very long delays (15 - 30 seconds) > > during the first call. The method RAND_poll() called from > > RAND_status() was identified to cause this. > > > > [...] > > > Just one shot from the hip, can it be possible that you have > directories in your PATH which are not acessible or are > located on another computer which is currently down? > OpenSSL on Win32 tries to load several DLLs on the first call > to RAND_poll and therefore Win32 has to go through the PATH > to find them. > > If there are invalid network directories in PATH Win32 needs > some time to find out the facts...
Thanks for the tip, Ted. I should have written more about the
testing system. It is a VMware hosted installation, a cleanly
installed Sharepoint 2003 server, where all paths are to the
local windows directories and to our application directory.
Another machine, where I run the small C++/.NET tests is
normal Windows XP with only local directories in PATH. All
directories on both systems exist.
Sometimes I had 10-20 ms delay in LoadLibrary, when the
system was under a bigger load, but...
I made an extra "crazy" logging in a separate file from the whole
method with entries for every call to be able to see which call
does it. The slowness came directly from the loop where is the
heap-walking, other parts were fast. Here is an example:
RAND_poll: fopen(perflog_logfile): 0
RAND_poll: GetVersionEx: 0
RAND_poll: 4x LoadLibrary: 0
RAND_poll: 2x GetProcAddress: 0
RAND_poll: 2x netstatget: 16
RAND_poll: FreeLibrary: 0
RAND_poll: All Network: 16
RAND_poll: 3x GetProcAddress: 0
RAND_poll: 2x CryptGenRandom: 15
RAND_poll: LoadLibrary: 0
RAND_poll: All CryptoAPI: 15
RAND_poll: readtimer: 0
RAND_poll: GlobalMemoryStatus: 0
RAND_poll: GetCurrentProcessId: 0
RAND_poll: All Status: 0
RAND_poll: 3x GetProcAddress: 0
RAND_poll: GetForegroundWindow: 0
RAND_poll: GetCursorInfo: 0
RAND_poll: GetQueueStatus: 0
RAND_poll: FreeLibrary: 0
RAND_poll: All Windows: 0
RAND_poll: 12x GetProcAddress: 0
RAND_poll: Heap(471): 297
RAND_poll: Processes(45): 0
RAND_poll: Threads(506): 16
RAND_poll: Modules(45): 0
RAND_poll: ?x CloseHandle: 0
RAND_poll: FreeLibrary: 0
RAND_poll: All Kernel: 313
RAND_poll: All: 344
What is interesting, 471 heap entries takes much more
time than 506 thread entries. OK, I can understand the
slowness, if many big heaps are present; this code is
run the worst count_of_heaps * 80 times:
RAND_add(&hentry,
hentry.dwSize, 5);
> I myself have never seen such a slow RAND_poll, so I'd think
> the problem has to be located somwhere on your computer.
Neither have I, until now... :-) What is interesting, this extrem
slowness occurs only in our testing VMWare host (installed
clean from the scratch). A standalone machine behaves cca 10
times faster, but still is the heap walking almost 20x slower as
the other ways of computing entropy.
Do you think, that the heap-walking gives an amount of entropy
worth its performance costs? (Only the thread-walking can give
more.)
> Hope it helps,
> Ted
> ;)
Well, I solved it for me by patching the openssl in our production
as our release draws nearer and nearer. I am attaching the file
with the extended logging and the diff to rand_win.c which turns
the heap-walking off, if anyone are interested. I can also test it
further, should you like to have more information.
thank you,
Ferda
rand_win.c.logging
Description: rand_win.c.logging
rand_win.c.diff
Description: rand_win.c.diff
