Recognizing Your Limits
At some point, you will either reach the limit of your responsibility or maybe even the limit of your skill level.
At this point, you need to make a decision on the state of the application. Consider the following scenarios:
Scenario 1—You have met the business delivery requirements.
Scenario 2—You have optimized as far as you can given the infrastructure and application profile, but have not met the business delivery requirements.
In Scenario 1, you have achieved the objective of meeting the business delivery requirements. (In Acme's case, every order response from the warehouse server is less than 4 seconds.) You can consider the issue resolved. (As discussed, the optimization process is a constantly evolving process.)
In Scenario 2, you have effectively gone as far as you can go. You have applied all QoS strategies to improve the application architecture, but the application performance is still not meeting the business requirements. At this stage, you must take steps to escalate the situation further. How you do this depends on what level of optimization was achieved. You can determine this by studying the metrics collected at the relevant demarcation points.
Each metric reveals application performance status; this in turn indicates areas that need improvement, such as an increase in bandwidth or even server CPU speed. You can find details about how to collect and apply these metrics in Chapter 8, "Monitoring the Delivery," and in Chapter 10, "When Applications Fail."
In Acme's case, the response time received at the metric point reveals that the warehouse server is taking 7 seconds to respond. Investigation by Acme revealed that the requests are being received at the warehouse database in good time, but the database server is taking an excessive time to process the response.
Assuming these metrics do not bring up more areas for you to optimize, your decision must then be to escalate. The metrics will identify the area of responsibility (more specifically the third party or vendor) that needs to address some issues. By establishing this audience, you will be in a position to deliver a clear and concise message conveying the true impact to your application-delivery model, enabling the audience to make recommendations for improvement. You can then verify these using your virtual environment, as described in Chapter 2, "Understanding Your Business."
Acme was able to identify the most probable cause of concern to be the warehouse server architecture. This conclusion was reached by simple refection on their metric collection. The web server showed it was sending and processing the requests in time, and the speed across the network (when a response was received) showed no congestion, drops, or latency, so by elimination, the area of concern and responsibility was the warehouse database server. The database administrators confirmed that the database was optimally tuned, so the last area to address was the server architecture. This is a simplified example, but it helps to illustrate how the observations at specific demarcation points ultimately assist in identifying the most probable area of concern.