OpenStack Swift

Chapter 17. Benchmarking

Martin Lanner

Darrell Bishop

The two previous chapters covered various operational considerations and best practices, as well as how to handle hardware failures and recovery. Of course, when you have a Swift cluster running, or maybe even before you do, you will inevitably ask: “How will this cluster perform?”

After all, you don’t want to buy and put something in production that can’t meet the needs of your applications and users. Hardware, size, services tiering, use case, and tuning all greatly affect how a Swift cluster performs.

That said, performance questions and concerns usually stem from the experience of having bought a storage system that doesn’t live up to expectations, which often results in having to upgrade the storage platform for a considerable cost. On top of that, when it comes to upgrading SAN and NAS systems, it usually also involves forklift upgrades from the old system to the new system, which in turn comes at considerable additional labor cost and frequently requires some amount of system downtime. This is not the case with Swift, an important factor to keep in mind. Compared with traditional storage, a Swift cluster is very adaptable and can be easily expanded or reconfigured to provide better performance if needed, all without requiring forklift upgrades or any downtime.

Because object storage platforms in general work in a very different manner from traditional storage platforms, including scaling out instead of scaling up, and can run ...