Acceleration vendor marketing departments push out a huge body of misinformation every day. You have read the headlines: "We speed up your application response time 400X!" What does that actually mean? What is the math behind a 400X change? Here's the answer.
Take an example in which the base (pre-acceleration) response time for an application task (the time from when the user hits enter to when the screen refreshes) is 8 seconds. When the acceleration technique is applied to the application traffic flow, the same task now takes 2 seconds. The 6 second difference is a very respectable improvement which many users will notice.
You can use three time values to calculate the response time improvement: 8 seconds, 2 seconds, and the difference between them which is 6 seconds. Now let's calculate how much "better" performance is.
The correct approach is to calculate the improvement as a percentage-divide the change (6) by the base (8) yielding a number that is less than one (in this case .75) and multiply by 100. In this case the new time is 75% faster than the original time.
The incorrect approach is to divide the base (8) by the new time (2) yielding a number greater than one which in this case is 4. Mathematically this result does not tell you how much faster the time is with the device, but rather how much slower the time would be if you stopped using the device: i.e., the time would increase from 2 to 8 seconds. The brochure will call this a 4X improvement. This method is mathematically wrong because if you were to stop using the device, the change would be 6, which is a three-fold, not a four-fold shift from 2 to 8. So the correct change will be 3X.
All of this is to impress a gullible consumer with a number that is bigger than the other guy's. Saying that something is 3 times faster sounds so much more impressive than saying it is 75% faster. We know our readers are not gullible but might benefit from putting these claims into perspective by using the following guide.
First of all, there is no way that any device can reduce response time by more than the base time. If you start at 8 seconds, the absolute fastest you can make an application respond is in zero seconds. That is a 1X change less than the base. Any value greater than 1X means completing the task in negative time! For example 3X faster than 8 seconds means 24 seconds faster than 8 seconds which is minus 16 seconds. Unless the vendor is also delivering an alternate universe, he is flat wrong.
Now that we know claims of 10X or 100X are actually dividing the base by the new values, we can convert back to the correct result. For example a 10X claim really means that 10 became 1 which is a difference of 9. So the improvement was 9 divided by 10, which equals 0.90 or 90%. That is even better than our first correct example which yielded a 75% improvement.
It is interesting that a 20X claim is really a 95% improvement, 100X is 99%, and 200X is actually 99.5%. Now you can see that in fact, all of the big-X claims are actually very close in true performance. It may sound compelling to buy a box from some vendor due to a 100X versus 10X claim. But your users will not notice the actual 9% true performance improvement difference (the spread between 99% and 90%). And any claim that is greater than 100X is working on the last 1% of time left before response time reaches zero. How much are you willing to pay for that?
Our advice is to tell the sales rep that you are ignoring all speed improvement metrics above 5X. Then focus on other more useful factors to evaluate WAN acceleration vendors.
NetForecast is an internationally recognized engineering consulting company that benchmarks, analyzes, and improves the performance of networked data, voice, and video applications.
|
|
Simple Math
While the method of calculation explained here is correct, one needs not to go to that pain and length. There are simple tools out there, some free of charge, that will make measurements easier, e.g. DU Meter. Turn on the Stop Watch that normally comes along with such tools, run your apps, turn off your acceleration, run the apps again in the same environment, just comapre the two results in terms of bps (bits per second)and you arrive at a more meaningful conclusion.
For example, you get an average 8Mbps rate result for your first test run, and a 1Mbps after acceleration is turned off, it is not even a math required to get the conclusion of 8X improvement in this case.
Simple math?
Actually from 1 to 8Mbps is 7 times improvement, you already had that 1. Or it might be less if happens gradually, think as 1 to 2 improvement is 1(yes, it is two times the original, but improved just 1 unit), 2 to 3 is 0.5, 3 to 4 is 0.333.. etc and add those improvements to get the final total. Or if you use some other model and/or words to present it can be something else. Heh!
Guess why percentages and times improved/bigger/smaller are used in statistics, marketing, sales, political polls, etc? Just because you can tell almost any story you want - if the listener / buyer doesn't ask the numbers and how you got to that result. Try sometimes when your shop has 30% discount sale. Strange it is not the same amount if they raise the prices 30%? Work out why and to what direction it is smaller and to what direction it is bigger. Or why governments love to give some statistics in numbers, some in percentages and use the words bigger / smaller / growth / etc but never explain what they mean by those?
Anyway, a good article and a good reminder but let's not start this again - it has beaten to death in Internet many times over. Last one in Slashdot created interesting emotional wars!