One of the advantages of enterprise super fast storage, such as the Kaminario K2, is that it can reduce or eliminate application tuning. Rather than tuning an application that is not performing well, you can achieve greater performance by moving the data to much faster storage.

Why would a company prefer to avoid tuning?
First, it is time-consuming and the cost of both labor and resources can be substantial. In addition, the tuning will most likely require adjustments to other tasks and projects, as those same resources will be used during the tuning effort. Also, in some cases, the company does not have access to the application source code (as in the case of third-party software), which makes tuning challenging and sometimes even impossible. The company might not have the required skills and tool set to perform the tuning task, or the required nonproduction environment in which to work. On top of that, many companies are concern that the tuning process will yield no major improvements. For example, the tuning effort might reveal that the bottleneck is disk I/O that can only be solved by replacing the storage. In short, there are many reasons to avoid tuning. On top of that, tuning is often a never-ending process that requires regular maintenance.

When do you decide to add a high performance storage appliance rather than tune your application?

The decision to integrate a high performance appliance within your storage environment comes once you have established the cause of the bottleneck. If the majority of the application processing time is I/O wait, and if that is the most significant wait event for any given application, then bringing in higher performing storage is the way to go. To better understand I/O wait, refer to our first posting, What Is “I/O Wait”?

When are both performance tuning and a high-performance appliance required?
It is not uncommon that you will need to do some additional testing to really understand the root cause of application performance bottlenecks. In some cases, there might be multiple causes in addition to I/O wait that are not so obvious, such as high CPU utilization, locking network delay, etc. Though off-loading high I/O applications onto a high-performance storage appliance can help alleviate I/O wait issues, it cannot totally resolve all performance issues if the application is written in such a way that it consumes large amounts of CPU cycles. If multiple performance issues exist along with I/O wait, then the combination of tuning and high performance storage can be the perfect solution.

Let us look at the example below, taken from a customer application on which I was recently working. It demonstrates that after application tuning, the high performance Kaminario K2 DRAM storage appliance still enabled the application to realize a significant improvement in performance. Obviously, this is a simple example that does not represent an entire application, but it is sufficient to demonstrate the point that sometimes, even after tuning, adding the right storage is mandatory to achieve the best results.

The application consisted of a CDR application batch process that was loading data records to the database. Each transaction loaded a new record (which is inefficient by itself, but was mandatory for business reasons). On every record that was loaded, some business logic was performed that involved reading data from other tables. The performance problem was obvious, as the batch was not able to load the entire data load in time. In fact, the load was a poor 10 rows per second. I tested the batch with the Kaminario K2 and was able to double the rows per second to 20, but knew that it could do much better. Something else was standing in the way.

An examination of the individual queries revealed that a single query consumed most of the transaction processing time. It was a select statement that was using an index scan, rather than an index seek, as a result of data-type mismatch. The query took 80 ms to complete. Once tuned, it completed in 1.2 ms. After the fix, the batch with the original storage was able to load about 50 rows per second. This was a little better, but the log latency was now the bottleneck, with significant I/O wait time. After a test of the new batch with the Kaminario K2, the application transaction processing showed a significantly higher load rate of 460 rows per second.

The following table summarizes the transaction processing rate results in number of rows loaded for each of the tests with the existing storage after tuning and then with Kaminario K2.

Application Transaction Processing Rate
Existing Storage Before Tuning	10 rows per second
Existing Storage After Tuning	50 rows per second
With Kaminario K2	460 rows per second

The following graphic illustrates how the combination of tuning and the Kaminario K2 storage appliance enabled the transaction rate to climb from 10 rows/s to 50 rows/s and then to jump 460 rows/s.

To summarize, application tuning will only address specific performance issues and will get you only so far. In this case, application tuning was a must, not an option, to maximize the performance optimization properties of any high performance storage appliance. In addition, the right high performance storage solution, such as the Kaminario K2, is required to fully realize the benefits of application tuning.

Tags: Application Performance Tuning, Disk latency, DRAM-based SSD Appliances, I/O bottlenecks, I/O wait, SSD appliances, Storage appliances, Storage Performance