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. This paper also discusses various ways to enhance the performance of Web-based applications.

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
It 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 include file instead of ten. Practically, this is not possible as more than one developer may be working on the same Web page at one time. Segregating logic in several modules can allow developers to work simultaneously. Depending on the working relationship between developers, and team dynamics at the time of the build, a single include file can be generated to receive minimum 304s.

All images and cascading style sheets will be requested exclusively. It is more advisable to have one background image than four images joined to make one background image. It is advisable to have one CSS file than to have three for the same page. It is also recommended that gif and jpg files be optimized with the proper graphical tool. Using 256 colors instead of 32 will increase the file size. For example, saving the "Click Me" image with 32 colors (gif) gives 898 bytes of image size. But saving the same image with 256 (gif) colors will give 2.131K, and saving it as a jpg gives 2.83K of image size. Clearly, if the image quality does not suffer, to save network bandwidth the preferred file format should be gif with 32 colors.


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.