We have tested our implementation on two Linux machines communicating with each other. One of the machines is a 200MHz Pentium processor workstation while the other is an older laptop machine with a 66MHz 486DX2 processor.
Some simple experiments were carried out to assess the impact our modifications have on performance. Two identical directory trees were created on each of the machines. The trees contain a total of 2,876 files and 115 directories. The built-in time command of tcsh was used to time two different commands performed on the directory tree. The first command was a full recursive listing of all files using the Unix command `` ls -lR''. To execute this command, the attributes for every file must be fetched from the server. The second command was designed to read about 6 Mbytes of data from the directory tree. This was achieved using the GNU tar command. In both cases the output was discarded by directing it to /dev/null. The operations were carried out using both the unmodified and the modified server, and in both possible directions. To make sure the servers did not use any information cashed from previous calls, the servers were restarted and remounted before running each command.
Table 5.4 shows the results from the ``list'' experiments and
table 5.5 contain the results from the ``read'' experiments.
Each entry contains the total time taken to execute the command. All values
are computed
means from three test runs.
Table 5.4: Execution times for ls -lR command
Table 5.5: Execution times for tar command
From the results we see that our modifications incur a rather heavy performance penalty that is relatively larger when the server is running on the machine with a slower processor. Even though the values shown for the faster machine seem to be acceptable, it is obvious that our rather straightforward implementation needs further refinement. For instance, information about active roles and permissions assigned to roles are currently kept in simple disk files. Here caching and use of in-memory databases can probably reduce the number of necessary disk accesses significantly. Also, our modifications to the original server are not primarily written with performance in mind. A tighter integration between base code and modifications is very likely to improve performance.