Building Performance into Internet Applications

Web applications are based on client-server, request-response mechanisms. Performance of any moderate- to high-functional Web application is directly proportional  to the architectural decisions and the technologies chosen to support it. Performance  also depends on the architectural awareness of a programmer and his ability to  address it from the inception phase of any Web-based application. The purpose of this  paper is to discuss various aspects of enhancing performance of a Web-based  application. The paper will provide illustrations and discussions to address these aspects.

High-Level Architecture
At a high level, Web applications are usually divided into four basic layers. Layers 3 and 4 are optional and are chosen based on product requirements:

1. presentation layer (client side/user interface)
2. distribution layer (server side)
3. business logic layer
4. back end (database/external dependency)

The general flow of this architecture is as follows: The client (presentation layer) will request a URL. A Web server (distribution layer) will receive the request and carry the preliminary processing. Based on processing, the Web server will call the business logic layer. The business logic layer carries out further processing based on encapsulated business rules. The business logic will also interact with back-end database applications as well as any external applications. The business logic will return control to the Web server when processing completes. The Web server will send a response to the client.

Minimal Code over the Wire
The intention of any Web-based application developer is to make sure that minimal code goes over the wire. The speed of Web page loading into any Web browser is directly proportional to the speed of the client's network connection. Normally, Web page size ranges from 20-35K. Anything above 35K will lead to degradation in service. If the Web server is located on the other side of the globe, the time for data to travel will be proportional to distance and speed of the network. The deciding and controlling factor will be the size of the code traveling over the wire.

Content Expiration and 304s
t is sent to the client can be given an expiration date. Web servers can be configured to make data expire after a day, a week, or a month. The duration of expiration depends on how frequently the Web page is updated. If the Web page is updated every few hours, this setting may result in misleading information. But if the data is not frequently changed, this setting can be very handy. One request and response can be composed of multiple data packets. If the client browser requests a GIF file that the server has recently delivered, the server will send "304" back to the client notifying that it already has been delivered. The client browser will retrieve that file from the local cache (temporary Internet file folder). It is an excellent mechanism to save network bandwidth. But the client has to make a round trip before it realizes that the requested content already exists as part of the cache. Setting a content expiration on the Web server will prevent this from happening. In this case, the client will search its cache first before asking the server for it.

Include Files and Graphics Optimization

ASP/JSP pages and HTML pages can have "include (.js, .vbs, etc)" files to organize the code base and deliver the intended functionality. All of these include files will have to be delivered to the client before the client browser can process the request. The client browser will have to request these files sequentially and exclusively. In normal circumstances, each request has to bring all corresponding files down to the client. It is advisable to have one