This section evaluates Pangaea's performance in a LAN using a sequential workload without data sharing. While such an environment is not Pangaea's main target, we conducted this study to test Pangaea's ability to serve people's daily storage needs and to understand the system's behavior in an idealized situation.
We created a variation of the Andrew benchmark6 that simulates a single-person, engineering-oriented workload. It has the same mix of operations as the original Andrew benchmark [13], but the volume of the data is expanded twenty-fold to allow for accurate measurements on modern hardware. This benchmark, denoted Andrew-Tcl hereafter, consists of five stages: (1) mkdir: creating 200 directories, (2) copy: copying the Tcl-8.4 source files from one directory to another, (3) stat: doing ``ls -l'' on the source files, (4) grep: doing ``du'' and ``grep'' on the source files, and (5) compile: compiling the source code. We averaged results from four runs per system, with 95% confidence interval below 3% for all the numbers presented.
Table 2 shows the time to complete the benchmark. Throughout the evaluation, label pang-N stands for a Pangaea system with N (gold) replicas per file. Pangaea's performance is comparable to NFS. This is as expected, because both systems perform about the same amount of buffer flushing, which is the main source of overhead. Pangaea is substantially slower only in mkdir. This is because Pangaea must create a Berkeley DB file for each new directory, which is a relatively expensive operation. Pangaea's performance is mostly independent of a file's replication factor, thanks to optimistic replication, where most of the replication processing happens in the background.
Coda's weakly connected mode (coda-w) is very fast. This is due to implementation differences: whereas Pangaea and NFS flush buffers to disk after every update operation, Coda avoids that by intercepting low-level file-access (VFS) requests using a small in-kernel module.
![\includegraphics[width=5in]{graphs/andrew_net.eps}](img20.png)
|
Figure 7 shows the network bandwidth used during the benchmark. ``Overhead'' is defined to be harbingers and update messages that turn out to be duplicates. Pang-1 does not involve any network activity since it stores files only on the local server. Numbers for pang-3 and -4 show the effect of Pangaea's harbinger algorithm in conserving network-bandwidth usage. In this benchmark, because all replicas are gold and they form a clique, Pangaea would have consumed 4 to 9 times the bandwidth of pang-2 were it not for harbingers. Instead, its network usage is near-optimal, with less than 2% of the bandwidth wasted.
Table 3 shows network bandwidth consumption for common file-system update operations. Operations such as creating a file or writing one byte show a high percentage of overhead, since they are sent directly without harbingers, but they have only a minor impact on the overall wasted bandwidth since their size is small. On the other hand, bulk writes, which make up the majority of the overall traffic, incur almost no overhead.
|
![\includegraphics[width=5in]{graphs/andrew_latency2.eps}](img21.png)
|