Defying Physics on the wire! (or seeming to…)
Last week, Percona published the first of several benchmarks they are performing on ScaleArc’s software to judge its performance and reliability. Percona is a trusted source in the MySQL community, known for being driven by those exact two factors, performance and reliability. We wanted to make sure that a third party validated all the hard work we’ve been putting into making ScaleArc the fastest, lowest latency, highest performance option available in the MySQL traffic management space. Percona ran ScaleArc's software through the grind, and at times we heard from them that the results surprised them, as the software seemed to do stuff which seemed physically impossible.
One of the most frequently asked questions that a lot of customers have is around the added latency that ScaleArc would introduce in their setup, as it is, at the end of the day, another bump in the wire, and an extra network hop would have to show its impact somewhere. In Percona’s testing, they expected that ScaleArc would obviously be faster than MySQL’s in-memory performance when the cache is turned on, but never expected us to be faster without caching. As they ran their tests at low concurrency (1-16 connections/threads), their hypothesis proved right. There is no defying physics. That added bump in the wire is going to be visible somewhere or the other, but they couldn’t find any more added latency beyond that of the network hop, which, in Percona’s own words means “ScaleArc by itself introduces immeasurably low latency.
The next part shocked them. When they tested with higher connection/thread counts (32 – 4096 connections, where most practical production MySQL loads lie), they found going to the database via ScaleArc was faster than going directly to the database server, even without any caching, load balancing, and connection multiplexing benefits as there was but one server behind ScaleArc. This shouldn’t be possible, but data doesn’t lie! The reason why going via ScaleArc is faster in this case is because ScaleArc schedules traffic in a much more predictable way over the wire, eliminating microsecond level bursts and valleys and thread randomization and contention at the server end, which actually reduces the context switches on the server side, and makes the server perform faster. Add benefits such as load balancing, connection pooling and multiplexing, and response time based load balancing, and the performance goes even beyond that gap, at times being as much as 2-4x faster than going straight to the database, despite no caching whatsoever.
And then comes the Cache! Even though the MySQL server in this test was running in an extremely optimized, very small dataset, in-memory only mode with no disk latency to slow it down, the cache was always 6-10x faster than the MySQL server, even in pure read-only mode, where the MySQL server is at its most performant, not having to deal with table locks and other such issues which can slow it down even further.
The upshot of these tests? They definitively show how ScaleArc is optimized for high-load, ultra-low-latency environments. In the coming weeks and months, we’ll be releasing more benchmark results – both from Percona and our own internal testing – covering failover, competitive testing, and application-specific testing.
Keep coming back to our blog to see these new results.
comments powered by Disqus