Scalability of Fleet Object Store Charles Fry Fleet is a distributed, quorum-accessed, Byzantine fault-tolerant object store, which currently has a tokenary implementation supporting nested method invocations (i.e. method invocations from one replicated object to another). Previously, only a minimal performance analysis was performed of this implementation, due to limited server availability. Now I have 78 servers at my disposal, and I propose performing the following scalability tests on nested method invocations in Fleet: - Measure response time and throughput of single method invocations (no nesting) as the number of servers and the number of tolerated faults grows. - Measure response time and throughput of nested method invocations as the number of levels of nesting grows. - Measure response time and throughput in the face of simulated failures, both crash and Byzantine. - Compare the performance of MACs versus signatures as the number of servers grows. The ultimate goal is not merely to measure the performance of Fleet, but also to understand why it behaves as it does, and then to optimize its performance. Inasmuch as time permits, each type of analysis will thus lead to modifications of Fleet in an effort to maximize its performance.