Bookshelf Home | Contents | Index | Search | PDF

Testing Siebel eBusiness Applications > Execute Performance Tests > Overview of Executing Performance Tests >

Monitor Failed Transactions

---

Less than 1% of transactions should fail during the measurement interval. A failure rate greater than 1% indicates a problem with the scripts or the environment.

Typically, transactions fail for one of the following three reasons:

Timeout. A transaction may fail after waiting for a response for a specified timeout interval. This can be caused by a resource issue at a server tier or by a long-running query or script in the application.

If a long-running query or script is applicable to all users of a business scenario, it should be caught in the SQL tracing step. If SQL tracing has been performed and the problem is only seen during loaded testing, it is often caused by data specific to a particular user or item in the test database. For example, a calendar view might be slow for a particular user because prior load testing might have created thousands of activities for that user on a specific day. This would only show as a slow query and a failed transaction during load testing when that user picks that day as part of their usage scenario.

Long-running transactions under load can also be caused by consumption of all available resources on some server tier. In this case, transaction response times typically stay reasonable until utilization of the critical resource closely approaches 100%. As utilization approaches 100%, response times begin to increase sharply and transactions start to fail. Most often, this consumption of resources is due to CPU or memory on the Web server, application server, or database server, I/O bandwidth on the database server, or network bandwidth. Resource utilization across the server tiers should be closely monitored during testing, primarily for data gathering purposes, but also for diagnosing the resource consumption problem.

Very often, a long-running query or script can cause consumption of all available resources at the database server or application server tier, which then causes response times to increase and transactions to time out. While a timeout problem may initially appear to be resource starvation, it is possible that the root cause of the starvation is a long-running query or script.

Data Issues. In the same way that an issue specific to a particular data item may cause a timeout due to a long-running query or script, a data issue may also cause a transaction to fail. For example, a script that randomly picks a quote associated with an opportunity will fail for opportunities that do not have any associated quotes. Data should be fixed if error rates are significant, but a small number of failures do not generally affect results significantly.
Script Issues. Transaction failures can also be caused by defects in scripts. Common pitfalls in script recording include the following:
Inability to parse Web server responses due to special characters (quotes, control characters, and so on) embedded in data fields for specific records.
Required fields not being parameterized or handled dynamically.
Strings in data fields that are interpreted by script error-checking code as indicating a failed transaction. For example, it is common for a technical support database to contain problem descriptions that include the string, The server is down or experiencing problems.

Bookshelf Home | Contents | Index | Search | PDF