ColdFusion Tips and Tutorials

Keep Coding,
Nathan Stanford
http://www.cftipsplus.com
admin<at>cftipsplus.com

If you have suggestions for articles send them to us.
If you would like to write for cftipsplus.com
send us an email to:

NathanS<at>nsnd.com

IF YOU WANT TO BE AN AUTHOR SEND IN YOUR COLDFUSION TIPS.

Remember this is a great way to get your name known in the
ColdFusion Community.

*Fusebox 4 released, more details at CFUN-03*
Fusebox version 4 was release in Atlanta GA today 5/7/03. Fusebox 4 will add new features using XML and compilation of the switch file. It also includes many ideas from FuseQ, the version of Fusebox written by John Quarto-vonTivadar that allow for multiple fuseactions and streamed output into CSS and Flash front ends. If you can't make it to Atlanta there will be four talks on Fusebox 4 at CFUN-03. The speakers include Hal Helms, Jeff Peters, John Quarto-vonTivadar and Sandra Clark. For more information see http://www.cfconf.org/cfun-03/

Overview
First, a timing review is in order. Knowing how many milliseconds it takes ColdFusion to execute the instructions on a page is not the same thing as knowing how long it took for the client's browser to receive and display the generated page. One interval is independent of network speed; the other is not. To time how long it takes to load a page, you have to start with the browser itself.
The most accurate way to do this from the client's standpoint would be to start timing when the client clicks "submit" and stop timing when the NEXT page has finished loading. This would include the time for the server to receive the signal and generate a response rather than just timing how long it takes the response to load.

However, this kind of instrumentation would be very hard to add after the fact. The start time would have to be passed to the server in a cookie, URL, or form field, compared with a time taken at the end of the next page load, and stored or displayed in some fashion.

The additional information the "perfect" method would provide may not be worth the effort in most cases. The page request itself is small compared with a page; so, its impact on the time perceived by the user is small. And, the execution time is not only small (if you've done your job right) but can be displayed by ColdFusion on the page itself during debugging. That leaves the page loading time itself, the subject of this tip.

If you could take a time hack at the beginning and end of every page and display the difference in the status bar, you'd have a simple means of determining how long every page took to load. That's exactly what you can do in eight lines.

Code
Place these four lines at the beginning of Application.cfm. ColdFusion automatically inserts code from this file at the beginning of every page request. This code will cause the client browser to stuff the number of milliseconds since a reference date into "startms".

<script language="javascript">
now=new Date();
var startms=now.getTime();
</script>

Place these four lines at the end of OnRequestEnd.cfm (creating this file if it doesn't exist). ColdFusion looks for this file in the same directory in which it found Application.cfm, and inserts code from this file at the end of every page request. This code will cause the client browser to check the millisecond counter again, subtract the previous count, and write the result to the browser's status bar where you can read it.

<script language="javascript">
later=new Date();
window.status=later.getTime()-startms;
</script>

Try it Out
This change won't write to the server, and it's overwritten by other status messages, but it appears unobtrusively in the status bar as each page finishes loading and can therefore be used by us in comparing the performance of new code to old. This change can be made to production code without harming it (assuming no conflict in variable names). Your clients probably won't notice the difference under normal circumstances, but your help desk folks can ask for this information when clients complain about slow load times. You'll learn HOW long troublesome pages take to load; so, you can decide how to allocate your scarce resources to make things better.

In theory, an application may have many Application.cfm pages: one in each of many directories. If it does, each one must be modified, and each one must have a corresponding OnRequestEnd.cfm in that same directory. However, that's easy to do.

If you often have one page call another, you may see a number briefly enter the status bar and then get replaced with still another number. Just watch carefully, taking your knowledge of the code into account. If you see zero fly by, you're using a cached copy and should clear your browser cache for accurate results (or you're testing on your own box and need to browse across a network instead for realistic results).

Try this; you'll like it. In just a few minutes, it will give you information you can't get in any other way without days or weeks of work.

=Marty=

SPONSOR ADS:
This e-mail is sponsored by the following ads.