M
Mike Johnson
Guest
Once we design these drivers, we have to measure them, right? Because you can’t improve anything you can’t measure.
The Performance Lab
This is an example of a graph that we generate out of our performance lab. It represents our JDBC driver and shows why memory usage is important. At the bottom, the number of threads from one to 10 represents the amount of memory that’s being consumed in megabytes which is shown on the left, from zero to 35 megabytes. Our drivers are fairly consistent—in blue here—but our competitor, shown in red, was using up a lot of memory.
Scaling the Experiment
They’ve improved over time, but when we saw the results, our first thought was “I wonder how many of our drivers we could run in the same memory space as our competition?”
So we did a little bit of magic here and added in and said, “We think we can get about five, and still consume less memory.” As an engineering organization that wasn’t good enough for us. So we went about proving it.
Let’s go through exactly what we did.
Over on the left side, you have the number of threads from 1 to 10, which simulates the number of users. And going across the top you can see Virtual Machines #1 through #3, as well as their combined total. The data within represents rows per second.
So in our lab, we set up the three virtual machines and we ran ourselves against the competition on each machine, and then aggregated them—all of them on the same physical box so we could tell when we were hitting scalability limits.
The Results
What we found is on the first virtual machine at ten threads, we were getting a little over 15,000 rows per second, and the competition was not doing as well. From the previous example, we knew they had memory consumption issues. Also, notice that you can add up all three of them, and the total throughput on all three different machines was a little bit over what we could do on a single virtual machine. So that’s 3X, a real-world example of the level of improved throughput that we could get with our driver.
What does this mean?
The drivers my team and I build here at Progress® DataDirect® are designed to be the fastest in the industry, and we stand behind that claim with award winning technical support. When you find performance degradation issues in our software, we treat them like defects because we understand how important speed is to your business. You can pick up a free trial today and try it out for yourself, or watch a replay of my webinar, “Industry Insight: Optimizing Your Data for Better Performance,” to learn more. Don’t forget to check back for the next installment of this series!
Continue reading...
The Performance Lab
This is an example of a graph that we generate out of our performance lab. It represents our JDBC driver and shows why memory usage is important. At the bottom, the number of threads from one to 10 represents the amount of memory that’s being consumed in megabytes which is shown on the left, from zero to 35 megabytes. Our drivers are fairly consistent—in blue here—but our competitor, shown in red, was using up a lot of memory.
Scaling the Experiment
They’ve improved over time, but when we saw the results, our first thought was “I wonder how many of our drivers we could run in the same memory space as our competition?”
So we did a little bit of magic here and added in and said, “We think we can get about five, and still consume less memory.” As an engineering organization that wasn’t good enough for us. So we went about proving it.
Let’s go through exactly what we did.
Over on the left side, you have the number of threads from 1 to 10, which simulates the number of users. And going across the top you can see Virtual Machines #1 through #3, as well as their combined total. The data within represents rows per second.
So in our lab, we set up the three virtual machines and we ran ourselves against the competition on each machine, and then aggregated them—all of them on the same physical box so we could tell when we were hitting scalability limits.
The Results
What we found is on the first virtual machine at ten threads, we were getting a little over 15,000 rows per second, and the competition was not doing as well. From the previous example, we knew they had memory consumption issues. Also, notice that you can add up all three of them, and the total throughput on all three different machines was a little bit over what we could do on a single virtual machine. So that’s 3X, a real-world example of the level of improved throughput that we could get with our driver.
What does this mean?
- Using the same virtual machine resource, we were able to get 45k rows while the competition got 15k rows.
- We can reduce the number of virtual machines per application by a factor of 3x
The drivers my team and I build here at Progress® DataDirect® are designed to be the fastest in the industry, and we stand behind that claim with award winning technical support. When you find performance degradation issues in our software, we treat them like defects because we understand how important speed is to your business. You can pick up a free trial today and try it out for yourself, or watch a replay of my webinar, “Industry Insight: Optimizing Your Data for Better Performance,” to learn more. Don’t forget to check back for the next installment of this series!
Continue reading...