Why is this java program running in IIS via PHP/FastCGI much slower than in shell?

Question

Today i came across a rather odd behaving java program.

Testrunning the java program in cmd shell results in a very fast execution (~0.5s). Accessing the same java via IIS with a PHP script results in a wait time of 5.5s on every request.

I added -Xprof to the java call to see how it behaves and found a recurring pattern like this:

Flat profile of 0.25 secs (24 total ticks): SeedGenerator Thread

  Thread-local ticks:
100.0%    24             Blocked (of total)

At the end we have the following time result:

  Thread-local ticks:
 91.4%   448             Blocked (of total)
  2.4%     1             Unknown: no last frame
lat profile of 5.04 secs (452 total ticks): SeedGenerator Thread

  Interpreted + native   Method                        
  0.2%     0  +     1    java.lang.Object.notifyAll
  0.2%     0  +     1    Total interpreted

     Compiled + native   Method                        
 99.6%    27  +   423    sun.security.provider.SeedGenerator$ThreadedSeedGenerator.run
 99.6%    27  +   423    Total compiled

         Stub + native   Method                        
  0.2%     0  +     1    java.lang.System.currentTimeMillis
  0.2%     0  +     1    Total stub


Global summary of 5.55 seconds:
100.0%   492             Received ticks
  1.8%     9             Compilation
  0.2%     1             Other VM operations
  0.6%     3             Unknown code

The code is spending 5s in the SeedGenerator during which java.exe consumes one complete cpu thread. I've tried running FastCGI with either impersonation on or off, it doesn't change the result.

Answer 1

There seems to be something very specific to how the FastCGI module spawns a new thread. My first guess was that creating the user environment for the impersonation takes a long time but as indicated in the question this is not true. However searching for problems with SeedGenerator i came across this answer: Simple Java program 100 times slower after plugging in USB hotspot

Using the suggested fix with changing java.security brought the execution time down to expected values:

Global summary of 0.53 seconds:
100.0%    43             Received ticks
 14.0%     6             Compilation
  4.7%     2             Class loader
  7.0%     3             Unknown code

Judging from the observed behavior it seems reasonable to assume that creating a new process through shell_exec using PHP on IIS with FastCGI does not provide anything that provider sun.security.provider.Sun could use for generating enough entropy for using crypto functions and therefore stalls the execution until enough entropy is created.