This article originally appeared as a Web Development Zone e-newsletter.
By Phillip Perkins
Consider this problem: Your client has a report in which data is queried from several different tables on the database server. Then this data is combined to produce HTML output to render in a Web browser.
When this report is generated, it takes several seconds to query the data and build the table before it spits out the HTML to the browser. Then, once the HTML information gets to the browser, it takes the browser a second or two to render the data. Since users would like to see something happen right away, the whole appreciation level for this report is far from its goal.
Here are the steps to the solution:
The data server is another tool to use to provide a portion of the complete solution. This means that the data server should serve as part of the data manipulation engine. If you have sales information such as quantity and price per unit, and you need to multiply the two to get a total sales figure, you should multiply the two at the data server and return the result as another field in your result set. This practice takes some of the load off the Web server and balances this load between two machines.
Maintaining a connection to your data server for the life of your ASP page is almost a necessity when you aren't using Microsoft Transaction Server (MTS). It's particularly expensive to create and destroy connections to a data server. For this reason, when you create a connection to query data from the data server, keep this connection alive until you are finished with the resource.
If you are using MTS to manage transactions, COM components, and connections, it's recommended that you destroy these connections as soon as you are finished with them. This is because MTS will cache the connection and keep it alive for other applications to use.
One of the most precious commodities in the Internet world is capacity. I'm referring to the size of the information that must be moved from one computer to another. When querying data, limit the amount of fields in your result set to only those necessary to the solution.
Also, if you're trimming your data on the Web server, it makes sense to trim the data at the data server and return it as a variable character data type. This has two advantages: You balance the work that it takes to trim the data, and you reduce the amount of useless white space coming across the network.
If the HTML isn't clean, Internet Explorer (IE) makes an attempt to render the HTML to the best of its ability. The rendering engine usually does a fantastic job. However, in order to make this educated guess, IE must receive all of the HTML data. Plus, it takes time for IE to calculate the output on large amounts of data.
To overcome this, it's a good idea to provide IE with clean HTML. For a table, this means that each TR must contain the same total number of TDs either in individual TDs or through the COLSPAN attribute. Use a COLGROUP to define the width of each COL in the TABLE. Finally, add the "table-layout: fixed;" style property to the TABLE's STYLE attribute.
If all these things are specified, you can flush data from the Response object buffer after each row as long as the Buffer property is set to True. This will immediately send the HTML from the server to IE, and since IE doesn't have to make a guess on rendering the table, it can start generating output. IE will continue to render each row individually until it receives all the rows.
Balancing the workload across your data server and Web server, managing your connections, limiting traffic on the network, and creating clean HTML are a few paths to speeding up your output in your Web applications.
Phillip Perkins is a contractor with Ajilon Consulting. His experience ranges from machine control and client/server to corporate intranet applications.