In this post, we will not be covering on the diagnostics of the application server, but we will cover the basic signs of database bottlenecks at the SQL statement level.  The 1^st symptom is a collective symptom that the application server (and all other servers) with the exception of the database server in the architecture are performing reasonably well.  E.g. memory available is well maintained without any exception decrease of this value, the processor % time is always low for the servers.

The 2^nd symptom is a constant high utilization of the processor % time and low memory usage (page faults, page reads and available memory) in the database server.  This provides a tell-tale sign that the database server is processing some instructions, likely to be SQL statement that is taking too long.  It would not be the database buffer or SQL buffer that utilizes the memory as the consumption is low meaning reuse of the buffer is high.

Now with these two symptoms, you are ready to go down deeper.  Access MS SQL and run the following query:

This query will sys.dm_os_schedulers will give you information of how many runnable tasks that exists.  Values other than zero indicate that tasks are waiting to run, and high values are an indication that the CPU is bottlenecking your performance.  Another query that directly targets at SQL statement is the following:

This query shows which batches or procedures are consuming the most CPU and will also include the actual SQL statement. The query aggregates by a specific plan handle. If the plan handle contains more than one SQL statement you must drill into each statement to determine where the greatest CPU contribution comes from.

Codes illustrated in this post are taken from DotNet Bob on SQL.

YSlow

• Download Component Size – YSlow provides the size of the downloaded component and provides suggestion in keeping the optimum amount of data size that the component should be. This include images, Javascripts, CSS and cookie size are just few of the examples.
• 

  YSlow Screenshot

  Bad Requests – It detects missing components that churns 404 errors.  Addressing 404 errors can help improve performance at the client and server end by removing requests made on missing objects as well as removing time needed to handle this requests on missing objects on the server.

• Detect duplicate requests/components – It detects duplicate HTTP requests made which degrades both the client and the server performance.  It also detects duplicate Javascripts which can result in duplicate request to the server or further slowing down the client browser.
• Placement of files – Another good feature made by YSlow is the detection of the placement of the Javascripts and CSS files.  The placement of the Javascripts and CSS files will help improve the performance at the client side.
• Detect expiry of components – YSlow can help determine if a component should be retrieved on every web page loading.  If a component such as an image (company banner) does not changed frequently, it is suggested to it expire at a far later date.  Else, for every time the page loads, a request will be made to the image.

What is great about YSlow is it provides you with the best practises for creating high performance web sites.  It helps you detect which components are too big and provide suggestions for you to improve the performance.  The best practises for high performance web sites can be found at Yahoo! YSlow Developer Network.

The disadvantage of YSlow is it is not installable on Internet Explorer, unlike HTTPWatch.  If you are a fan of the real-time analysing the response (wait) time on HTTPWatch, then you will be disappointed with YSlow on this.  YSlow does not provide any visual indicator on the time taken during loading (or requesting to the server) in real time.  It will only display the time only after the entire web page is downloaded.

The above are just some of the features that are available in YSlow.  You can download YSlow and start profiling your website. We hope to hear your review soon!

90% percentile allows us to know that for a certain amount of transactions are performing at a certain amount of duration.  Of course it’s a really abstract description but anyway how is it useful?  Example, if the 90th Percentile is 10secs, what it literally means is that 90% of all transactions are performing at or under 10secs.  While the remaining 10% are performing more than 10secs.  If you have a SLA or performance requirements that is based on 90% of the transactions to perform under 8secs, you have pass this criteria.

The Percentile can also tell you how the system is performing, such that if there is a higher percentage of slow response time transaction and what is the percentage that is performing higher than the expected transaction response time.  In a typical average transaction response time graph, you can see how the (passed) transactions are performing during the entire load test period over time.  However, the Percentile graph illustrates the (passed) transactions and their percentage with respect to the overall transactions.

In the below example taken from the Analysis User Guide, at the 60th Percentile, tr_amazon_help is at about 4secs, which means 60% and less of tr_amazon_help is responding at 4secs less.  While at the 90th Percentile, 90% of all tr_cnn_weather transactions are responding at 20secs or less.

• WASJDK: java.lang.OutOfMemoryError due to allocating large heap objects

For the latest version of the WebShere documentation and tuning guide, you can refer to the IBM Public Library for WebSphere 6.x where there are various resources for performance tuning WebSphere 6.x.

(Special thanks to Aravind Kumar for contribution, CSS Corp)

Usually, this happens when the the disk is very busy such as copying of large amount of files out copying multiple files, etc. We must first understand that whatever monitoring data Controller is displaying for Windows is based on Windows Perfmon. You can refer to the article titled, “How does the monitoring work in LoadRunner?” if you need some explanation. This is actually by design of the Windows OS.

The behavior can occur because the OS uses overlapping input/output operations for multiple outstanding requests. The disk performance counters time the responses by using a 100 nanosecond precision counter, and then report the cumulative statistics for a given sample time. This sample time could go over 100 percent if, for example, you have 10 requests that completed in 2 milliseconds each in a 10 millisecond sampling interval. If you have multiple disks in a Raid arrangement, the overlapped input/output happens because the operating system can read and write to multiple disks, and this could show values that are higher than 100 percent for this counter.

(Source: Microsoft Help and Support)

There is no quick fix to this as of this writing and the most accurate way to determine disk utilization is to use % Idle Time in the below formula:

100% – % Idle Time = Actual % Disk Utilization

Often when you add the % Disk Read Time and % Disk Write Time counters together, they do not add up to % Disk Time. Furthermore, the % Disk Time counters are capped in the System Monitor at 100 percent because it would be confusing to report disk utilization greater than 100 percent. This occurs because the % Disk Time counters do not actually measure disk utilization. The Explain text that implies that they do represent disk utilization is very misleading.

What the % Disk Time counters actually do measure is a little complicated to explain but Mark provided a detail explanation in the following paragraphs which required your attention to read through.

The %Disk Time counter is not measured directly instead it is a value derived by the diskperf filter driver that provides disk performance statistics. diskperf is a layer of software sitting in the disk driver stack. As I/O Request packets (IRPs) pass through this layer, diskperf keeps track of the time I/O’s start and the time they finish. On the way to the device, diskperf records a timestamp for the IRP. On the way back from the device, the completion time is recorded. The difference is the duration of the I/O request.

Averaged over the collection interval, this becomes the Avg. Disk sec/Transfer, a direct measure of disk response time from the point of view of the device driver. diskperf also maintains byte counts and separate counters for reads and writes, at both the Logical and Physical Disk level. (This allows Avg. Disk sec/Transfer to be broken out into reads and writes.)

The Avg. Disk sec/Transfer measurement reported is based on the complete roundtrip time of a request. It is a direct measure of disk response time- which means it includes queue time. Queue time is the time spent waiting for the device because it is busy with another request or waiting for the SCSI bus to the device because it is busy.

% Disk Time is a value derived by diskperf from the sum of all IRP roundtrip times (Avg.Disk sec/Transfer) multiplied by Disk Transfers/sec, and divided by duration, or essentially:

% Disk Time = Avg Disk sec/Transfer * Disk Transfers/sec

which is a calculation (subject to capping when it exceeds 100 percent).

Because the Avg. Disk sec/Transfer that diskperf measures includes disk queuing, % Disk Time can grow greater than 100 percent if there is significant disk queuing (at either the Physical or Logical Disk level). The Explain text in the official documentation suggests that this product of Avg. Disk sec/Transfer and Disk Transfers/sec measures % Disk busy. If (and this a big “if”) the IRP roundtrip time represented only service time, then the % Disk Time calculation would correspond to disk utilization. But Avg. Disk sec/Transfer includes queue time, so the formula used actually calculates something entirely different.

(Source: O’Reilly Network)