The Importance of Assurance in Performance.

The Importance of Performance Certainty

Until recently, a system’s design and database administrator’s work habits were primarily responsible for performance certainty. Uptime has been taken for granted since the concept of practically always-online database management systems (DBMS) for file storage spread among business executives. The go-to men were Amazon, Google, and other cloud infrastructure, suppliers. Performance became “the new black,” and uptime became less concerned.

You cannot, however, expect performance. You must be confident in the system’s functionality. You must understand what motivates performance and how system modifications could impact the performance profile. In conclusion, performance certainty refers to this.

This piece aims to outline the tactical measures you may take to ensure that performance—or the deployment environment’s specifications—are not left to chance. I’ll offer some tools to help you make sure the adjustments you make while no one is seeing (when the work is getting done) are recognized for their effects.

It’s a New World, Performance Matters

System or subsystem uptime used to be a problem for operations teams. The end-user experience and system effectiveness show today’s focus is on apps and application speed.

In the realm of chargebacks and the cloud, there is a more direct connection between performance, resource use, and cost. Some businesses, especially software as a service (SaaS) firms, spend money on infrastructure. The profitability, wellbeing, and long-term survivability of an organization can thus be directly impacted by system performance.

​​

We’ve Been Operating Without Performance Certainty

Decisions made by operations teams are frequently based on assumptions and hope. They act in this manner not out of choice but because they have no other option. I’ll give two instances to illustrate:

The first one concerns virtualization and databases. Because they were unsure how a database server would function in a virtual system, database administrators (DBAs) resisted transferring databases to virtualized settings for a long time (VM). They were uneasy with the new metrics and operational uncertainties of optimizing a VM, as well as the possible performance impact of running on a hypervisor instead of bare metal.

There was no assurance of performance.

Nowadays, 80% of databases operate in virtual settings. Without considering the databases running on EC2 instances, Amazon revealed publicly in 2015 that they generate $1 billion annually from the database as a system (DBaaS) software (RDS, Aurora, Dynamo, etc.). Performance can alter at any time due to the dynamic environment they are presently in, such as when a noisy neighbor or a database administrator moves a VM.

The second illustration is an actual incident. I assisted a client is using a SaaS application when I was employed by one of the leading cloud service providers. When I questioned them about why they said they added a cluster each time they launched a particular number of consumers.

The client reported that this model was effective. I inquired as to what influenced performance, thinking that perhaps we could assist them in increasing the capacity of each cluster by a factor of two. Was it a result of the group running out of memory, poor database performance, insufficient storage, or another factor? The client was in the dark. They didn’t have the time to experiment or the visibility to understand what drove performance or their bottlenecks; all they knew was what worked.

Trial and error is no longer an effective method of determining this because there have been so many changes and variables. Performance certainty is what we require—and what the company needs of our systems.

Performance Visibility Is a Prerequisite for Performance Certainty

Systems are dynamic and constantly changing. You swap out hosts, move virtual machines around, add new apps to the storage system, alter the load on each application, and more. Consider the continuing transitions to flash-based storage systems, converged architectures, and cloud migration as examples. Knowing the performance baseline and the relative importance of each component is critical.

The seven DevOps principles establish a performance orientation and the necessity of monitoring everything to obtain the necessary cross-team visibility into how each change affects the system from a performance and throughput standpoint.

What you can’t see can’t be fixed. You should be fully aware of how much your current storage system contributes to performance and how switching to faster storage would enhance performance in resource utilization and end-user experience before approaching finance about an AFA storage device.

It would help if you had a realistic idea of how your next workload will perform in the cloud, what resources it will require, and how much those resources will cost per hour before moving it to the cloud. You must also understand the major system components that can affect performance.

Seven Steps to Achieving Performance Certainty

So how can you ensure performance? Here are some suggestions that will each move you closer:

1. Embrace the discipline of execution. The primary statistic you use to gauge the level of work should no longer be the uptime. We presume uptime. How quickly can the system function? What resources do you have to analyze and enhance performance?
2. Take a response-time analysis approach. Time must become your primary concern instead of resource measurements, logs, and health. It includes every process, query, wait for the state, and time contributed by storage (I/O, latency), networking, and other parts supporting the database and the application. Here is how database performance relates to response time.
3. Identify a starting point. Establish the important KPIs, which should preferably be focused on application performance and end-user experience (again, not CPU utilization or theoretical IOPS). Using statistical baselines, you can better understand what is expected and when/how performance varies. Alerts based on baselines (which depend on critical performance data) allow you to focus on what matters.
4. Don’t wing it. Before shifting to faster hardware or provisioning more, understand the performance contribution of each component, which indicates its potential contribution to performance enhancement.
5. Become your team’s performance guru. Knowledge is power. With the change in IT toward performance, professionals who better understand performance, what drives it, and how to improve it are more critical to their employers.
6. Dashboards for performance are shared. Take credit for the performance gains you achieve. Inform management of the cost savings by reused equipment or postponed purchases—trade performance information. Be the one in charge. Report on the effects on performance and whether or not each infrastructure component and team member has improved it. Using your performance data, you can tell Joe that the code he produced this week is terrible. Compared to last week, it moves 25% more slowly. Here are the numbers.
7. The performance of the plan varies. If you can adequately estimate application performance before changes take place and direct your organization toward improved performance, you have performance certainty.

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of clouds, RDBMS, NoSQL, and machine learning database platforms.