Performance Issues
Enforcing access control rules requires runtime checks. So it is natural to ask: What are the performance implications? Will these runtime checks degrade the runtime performance of my application significantly? What factors impact this degradation? What can I do to better understand and manage it?
To answer these questions, let us do a simple experiment and collect some performance data. We write a program that carries out an access controlled operation in a loop and run it under different policies. Listing 5-14 shows such a program that retrieves a system property, by invoking the static method getProperty() on the System class, a security sensitive operation, inside a loop and times the loop. Many rounds of measurements are taken to ensure that the warm-up overhead of the first few executions don't skew the results.
Listing 5-14. Measuring the performance of System.getProperty()
// File: PerfTest.java
public class PerfTest {
public static int count = 1000000;
public static String PROP = "user.dir";
public static String getsysprop(String prop){
return System.getProperty(prop);
}
public static void main(String[] args) throws IOException {
if (args.length > 0)
count = Integer.parseInt(args[0]);
System.out.println(PROP + " = " + getsysprop(PROP));
String pv = null;
for (int r = 0; r < 4; r++){// Many rounds.
long ts = System.currentTimeMillis();
for (int l = 0; l < count; l++)
pv = getsysprop(PROP);
long te = System.currentTimeMillis();
System.out.println("Round[" + r + "], Elapsed time for " +
count + " iterations: " + (te - ts) + " milli secs.");
}
}
}
|
You will find the file PerfTest.java (and PerfTestLauncher.java, for running this program for a logged-in user), as well as different policy files and the execution script pt.bat under srcjsbookch5pt subdirectory of JSTK installation directory.
From earlier discussion in this chapter, we know that the different policies of interest are:
No policy (i.e., without a security manager);
A policy with permission to the program's jar file;
A policy with permission to the program's signed jar file;
A policy with permission to a specific user.
Table 5-4 lists the measured performance figures for a loop of 1000000 (one million) on a 900 MHz AMD Athlon machine running Windows 2000. The reported numbers are approximate averages for different rounds, excluding the first one.
Although you should be careful in using these numbers to draw concrete conclusions as a number of factors could skew results for a micro-benchmark like this, these numbers do give us a feel for the performance overhead. The overhead appears to be quite large in relation to the main operation, but this is so only because retrieving a system property value is a fast memory operation. The absolute numbers for the overhead of individual permission check appears to be quite low. Also, keep in mind that the kind of operations that are access controlled usually do not appear in tight loops. In a typical application, a user session is not likely to involve more than a few tens of access controlled operations.
| Measurement condition | Elapsed time for 1000000 operations (milliseconds) | Overhead per operation (microseconds) |
|---|---|---|
| Without security manager | 330 | 0.00 |
| Permission associated with jar file | 8933 | 8.60 |
| Permission associated with signed jar file | 8983 | 8.65 |
| Permission associated with jar file and a specific user | 29082 | 28.6 |
As the time consumed in access control check would be largely independent of the specific operation, let us focus on absolute numbers under different policies. We observe that the overhead is slightly more for signed jar but is almost three times more when the permission is granted to a specific user. Though not shown in the Table 5-4, the overhead per operation didn't change much with a change in the number of iterations in the loop (as long as the measurement window was large enough) for rounds other than the first one. In the first round, the first few invocations are quite slow as the various data structures get initialized.
Keep in mind that these numbers have meaning only under the measurement conditions. Access control check overhead for a real application would be very different and would depend on specific access control policies, implementation of the specific permission class, depth of calling stack with different protection domains, number and nature of configured login modules, number of system users, and so on. Though we used a micro-benchmark program to gain insight into the access control overhead, in practice it is preferred that you measure the overhead of access control checks for the application as a whole.