You Can’t Improve Anything You Can’t Measure

You Can’t Improve Anything You Can’t Measure

January 06, 2016 0 Comments

Once we design these drivers, we have to measure them, right?  Because you can’t improve anything you can’t measure.

The Performance Lab

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.

Real world scalability results

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

Web product details

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

Fastest in the Industry

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!
Mike Johnson

Mike Johnson

Mike is a proven leader with over 20 years of experience in developing commercial software for the industry leader in standards-based data access software. He has extensive experience in all aspects of commercial software development including requirements analysis, developing functional requirements, developing and mentoring individuals, staffing, budgeting, product development, quality assurance, training and customer communication. Mike has progressed in his career in large part from his strong work ethic and a “do whatever it takes” attitude.

Comments are disabled in preview mode.
Latest Stories
in Your Inbox

Subscribe to get all the news, info and tutorials you need to build better business apps and sites

More From Progress
2020 Progress Data Connectivity Report
2020 Progress Data Connectivity Report
Read More
Getting Ahead of the Hybrid Data Curve
Read More
Creating Quick, Codeless Connectivity with Autonomous REST Connector
Read More