Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
Once we design these drivers, we have to measure them, right? Because you can’t improve anything you can’t measure.
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.
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.
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?
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.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.