Page 286 - DCAP312_WEB_TECHNOLOGIES_II

Web Technologies-II

Notes These graphs focus on just two metrics namely, throughput and response time. A complete
baseline should contain data for several metrics but should always include basic metrics such
as throughput and response time because these most directly affect the user’s experience with
the application.

Search about the caching process. Differentiate between cache memory and RAM.

14.3.1 ASP.NET Performance
Creating Web applications that respond to user requests quickly, even when a large number of
requests are being processed on the server, has been a challenge for developers and IT personnel
since the Internet began. Monitoring Web site performance is something that all Internet and
intranet developers need to be able to do. ASP.NET was designed with this in mind.
The ASP.NET model provides a number of built-in performance enhancements that are not
included in earlier versions of ASP. Particularly, there are two enhancements involved in
processing HTTP requests. First, when an ASP.NET page is requested for the first time, an
instance of the Page class is dynamically compiled. (In earlier versions of ASP, page code was
interpreted for requests in the order that they appeared on the page.) The common language
runtime just-in-time (JIT) compiles ASP.NET managed page code to the native code of the
processing server at run time. Second, when the Page instance has been compiled for the first
request, it is cached on the server. For each subsequent request for that page, the cached instance
of the class is executed. After the initial request, the Page class is recompiled only when the
original source for the page or one of its dependencies has changed.
In addition, ASP.NET caches internal objects, such as server variables, to speed user code access.
As a part of the .NET Framework, ASP.NET benefits from the performance enhancements
provided by the common language runtime, including the previously mentioned JIT compiling, a
fine-tuned common language runtime for both single and multiprocessor computers, and so on.

These enhancements, unfortunately, cannot protect us from writing code that does not perform
well when a large number of HTTP requests are processed by our application simultaneously.
We must test our application to ensure that it meets the demands of its users. There are four
common performance measures that we can test to ensure that our application is performing well.
Execution Time
The time it takes to process a request, usually measured between the first byte and the last byte
returned to the client from the server. Execution time directly affects the throughput calculation.
Response Time
The length of time between when a request is requested and when the first byte is returned to
the client from the server. This is often the most perceptible aspect of performance to the client
user. If an application takes a long time to respond, the user can become impatient and go to
another site. The response time of an application can vary independently of (even inversely to)
the rate of throughput.
Scalability
The measurement of an application’s ability to perform better as more resources (memory,
processors, or computers) are allocated to it. Often, it is a measurement of the rate of change of
throughput with respect to the number of processors.

280 LOVELY PROFESSIONAL UNIVERSITY