Why test with randomly generated packets when you can capture real data and use that instead? Mu Dynamics is hoping this proposition can propel its newest test suite to the forefront of cloud-based services testing. On July 19, the company released Studio Scale, a testing suite that can capture traffic across multiple protocols, then regurgitate said traffic during test barrages.
Dave Kresse, CEO of Mu Dynamics, said that many existing scale-testing frameworks aren’t based on real traffic. The ones that are, he added, are typically focused on HTTP only. Studio Scale is designed to capture and replicate traffic of all kinds, from VOIP to video to chat and other protocols. This allows his company to focus on complex environments, and to give test developers a more flexible tool for putting Web services to the grindstone.
“We take service transactions and transform those into parameterized interactions,” Kresse said. “We take real traffic and, for the purpose of test, replicate those services and those components. This is true replication such that the application can’t tell if they’re in a real world or if they’re virtual.”
This approach is based on the more traditional methods of testing enterprise applications, he said. Specifically, desktop testing tools from now-acquired companies like Mercury and Rational were based on the idea of recording desktop activity and replicating it during tests. Most often, this was done in the form of capturing keystrokes and mouse clicks.
Kresse said Mu Dynamics used this philosophy in the creation of Studio Scale. Instead of mouse clicks, Studio Scale captures packets as they move from the server to the client and vice versa. Thus, a website based on sharing video could be tested with the traffic generated for uploading that video and watching it in the browser.
Studio Scale costs between US$100,000 and $125,000. The software is part of the company’s larger suite of fuzzing and verification products, said Kresse.
He added that the major differentiation for Studio Scale is its ability to replicate full transactions at scale rather than simply replicating simple communications concurrently. “The key is there’s really no ability to simulate or replicate the concurrent transactions anywhere else,” he said.
“When you’re doing some of these complex transactions, the stress happens in unexpected ways. It’s not a question of throughput; it’s a question of where the service stalls itself. It happens at much lower concurrency levels than you might expect. When you start to do the actual transactions, things come down at much earlier levels.”
