Sams Teach Yourself .Net in 21 Days

By Jason Beres

• Table of Contents
  • Copyright
  • About the Author
  • About the Technical Editor
  • Acknowledgments
  • We Want to Hear from You
  • Introduction
  • Week 1: At a Glance
  • Day 1. Introduction to the Microsoft .NET Framework
  • Day 2. Introduction to Visual Studio .NET
  • Day 3. Writing Windows Forms Applications
  • Day 4. Deploying Windows Forms Applications
  • Day 5. Writing ASP.NET Applications
  • Day 6. Deploying ASP.NET Applications
  • Day 7. Exceptions, Debugging, and Tracing
  • Week 1. In Review
  • Week 2: At a Glance
  • Day 8. Core Language Concepts in Visual Basic .NET and C#
  • Day 9. Using Namespaces in .NET
  • Day 10. Accessing Data with ADO.NET
  • Day 11. Understanding Visual Database Tools
  • Day 12. Accessing XML in .NET
  • Day 13. XML Web Services in .NET
  • Day 14. Components and .NET
  • Week 2. In Review
  • Week 3: At a Glance
  • Day 15. Writing International Applications
  • Day 16. Using Macros in Visual Studio .NET
  • Day 17. Automating Visual Studio .NET
  • Day 18. Using Crystal Reports
  • Day 19. Understanding Microsoft Application Center Test
    • Introduction to Application Center Test
    • Understanding ACT Projects, Users, Tests, and Connections
    • Using the ACT Standalone Application
    • Walking Through the ACT Script
    • Understanding the ACT Test Results
    • Summary
    • Q&A
    • Quiz
    • Exercises
  • Day 20. Using Visual SourceSafe
  • Day 21. Object Role Modeling with Visio
  • Week 3. In Review

Understanding the ACT Test Results

There are several pieces of information that help you figure out what the results of the ACT tests actually mean. The reports and performance counters are the most important tools you have to determine how your site will perform.

The two primary items you can determine from the reports are errors and page timings.

The errors are returned as response codes. All response codes in the 200s indicate normal operations. 100s are informational messages, 300s indicate redirection, 400s indicate a client error, and 500s indicate a server error. You saw the response codes earlier today in Table 19.1.

Page timings can be useful in determining the effect of either page coding or underlying database operations and caching. In the reports, this is primarily determined by looking at the TTFB (Time To First Byte) and TTLB (Time To Last Byte).

Noting these times and making changes to the logic or database access gives you a good way to track the resulting changes and make sure that you haven't introduced a delay you didn't mean to!

The performance counters for this testing, and many system problems as well, provide a wealth of information. The performance counters enable you to find when your clients and/or servers have reached their peaks in terms of processor, memory, disk I/O, and network throughput.

The idea is that you should make sure that the testing isn't bottlenecked by the client computer that's driving the testing. If the client computer CPU usage is above 90%, it's probably the limiting factor in being able to produce a load on the Web server.

By looking at various counters on the Web server, you should be able to determine performance issues. A rule of thumb is that the Web server CPU usage should be at least 80%. At that point, you'll see the maximum limit of the Web server and not the limitations of the client test computer.

Comparing RPS on various test runs will help you tune the Web server and the Web application.

Share This