Java Application (i.e., WebLogic Server) could be slow at startup time and it could be caused by the slowness of random number generator used by the application. You can read [2] for the case that discusses the slowness of WebLogic startup.
In this article, we will examine the following issues:
Without much ado, here is the man output for "urandom":
You can use "time" command to measure the performance of each random number generator. For example, here is the output from the Linux system.
$time head -1 /dev/random
real 0m9.718s
user 0m0.000s
sys 0m0.001s
Or, you can specify which source of seed data to use by adding
In [1], it warns that if you choose /dev/urandom over /dev/random for better performance, you should be aware of that:
In this article, we will examine the following issues:
- /dev/random vs. /dev/urandom
- How to test the performance of a random number generator?
- How to configure it?
- Security considerations
on Linux systems. Note that this can happen with WLS running on AIX too.
/dev/random vs. /dev/urandom
Without much ado, here is the man output for "urandom":
The character special files /dev/random and /dev/urandom (present since Linux 1.3.30) provide an interface to the kernel's random number generator. File /dev/random has major device number 1 and minor device number 8. File /dev/urandom has major device number 1 and minor device number 9.
The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created.
When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead.
How to Test?
You can use "time" command to measure the performance of each random number generator. For example, here is the output from the Linux system.
$time head -1 /dev/random
real 0m9.718s
user 0m0.000s
sys 0m0.001s
$ time head -1 /dev/./urandom
real 0m0.002s
user 0m0.000s
sys 0m0.002s
As you can see that "/dev/urandom" is much faster because it's non-blocking. However, /dev/random will block until additional environmental noise is gathered and takes longer time to return.
How to Configure?
You can configure which source of seed data for SecureRandom to use at JVM level or at WLS' command-line level.
At the JVM level, you can change the value of securerandom.source property in the file:
At the JVM level, you can change the value of securerandom.source property in the file:
- $JAVA_HOME/jre/lib/security/java.security
Here is the description of securerandom.source property:
# Select the source of seed data for SecureRandom. By default an # attempt is made to use the entropy gathering device specified by # the securerandom.source property. If an exception occurs when # accessing the URL then the traditional system/thread activity # algorithm is used. # # On Solaris and Linux systems, if file:/dev/urandom is specified and it # exists, a special SecureRandom implementation is activated by default. # This "NativePRNG" reads random bytes directly from /dev/urandom. # # On Windows systems, the URLs file:/dev/random and file:/dev/urandom # enables use of the Microsoft CryptoAPI seed functionality. # securerandom.source=file:/dev/urandom
Or, you can specify which source of seed data to use by adding
- -Djava.security.egd=file:/dev/./urandom
Security Considerations
In [1], it warns that if you choose /dev/urandom over /dev/random for better performance, you should be aware of that:
This workaround should not be used in production environments because it uses pseudo-random numbers instead of genuine random numbers.
References
- Random Number Generator May Be Slow on Machines With Inadequate Entropy
- Weblogic starts slow
- Fusion Middleware Performance and Tuning for Oracle WebLogic Server
- Oracle® Fusion Middleware Tuning Performance of Oracle WebLogic Server 12c (12.2.1)
- Fusion Middleware Tuning Performance of Oracle WebLogic Server (12.2.1.3.0)
No comments:
Post a Comment