Build engaging websites with intuitive web content management
Track, analyze and shape every step of the customer journey
Leverage a complete UI toolbox for web, mobile and desktop development
Build mobile apps for iOS, Android and Windows Phone
Automate UI, load and performance testing for web, desktop and mobile
Streamline business app development and management
Develop SaaS business apps with point and click ease
Run Node.js, PHP, Java and MongoDB at scale
Optimize data integration with high-performance connectivity
Rules Engine that improves productivity and lowers costs by automating your decision process
Transform your businesses in order to survive in a completely digitized and connected world driven by software innovation.
Comprehensive solution for crafting and managing sophisticated digital experiences
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
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 © 2016, 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.