Thanks for helping me out. Your suggestions were very helpful.
Interestingly, the improvement I implemented that made the most difference was
removing a call to an image to be displayed for each title. Although the image is
tiny (both physically & file-size wise), removing it reduced the actual load times by
25%.
The other two changes I made (de-modularizing the processing file and indexing the
table) reduced the execution time slightly (down to about 2800-3000 milliseconds), but
the load time was only negligibly reduced.
Adding "next N" or range methods would not effectively reduce the overall time it
takes for users to get to the title(s) they want. While they are "browsing", they are
looking for something specific. They are probably only "browsing" through the letters
because either they don't know the exact title (although I do provide a keyword
search) or they are used to that method because this is how they use our print
collection (our hard-copy journals are on shelves in alphabetical order).
Thanks, again, for your help.
Karen
>>> [EMAIL PROTECTED] 1/19/01 2:23:21 PM >>>
Karen:
3 things to examine for performance:
1st look at your execution time via your debug options. These measurements are the
"Processing" time the CF Application server needs to complete the request. How many
milliseconds does this template need ? 500, 1000, 5000, more ? Something over 2000 is
starting to get too high and if it is over 5000 pretty unacceptable outside of an
intranet. If your numbers are high, look at your queries and complexity of
statements.
This CF measurement has nothing to do with the time it takes the webserver to serve up
the page and for the client to download and display the result set in their browser.
That would be bandwidth, client, etc.
2) Take a look at the page properties, does the weight exceed 70,000k ?
is the whole list wrapped in a table. You might look at displaying N records at a time
on the screen and then a 1,2,3,... click buttons at the bottom a-la-alta vista that
you can view 20-30 rows at a time; this will greatly reduce the page size; because 300
or 600 rows of anything, even just a 50 character display of each row would be up to
30,000 characters if there are 600 rows and if you displayed 30 rows at a time 1,500
characters. That is a BIG difference in the page size.
3) You might also look at your CF settings in the CF Administrator regarding template
size / caching / processes. And make sure that you enable Enforce Strict Attribute
Validation (Checked)
When checked, strict attribute validation rules will be used. Extraneous attributes
will not be allowed for any tags in CFML. When not checked, irrelevant attributes may
be passed to CFML tags. Strict attribute validation improves template execution time
and allows for the prevention of many CFML coding errors.
Bob Coalter
At 01:33 PM 1/19/01 -0600, you wrote:
Execution time is the time it takes for CF to compile the page, run the
queries and return results to be displayed. The time it takes a page to
show up is based on BW, clients machine settings/speed, and for the page to
display. Your execution time should always be as low as possible, so that
the page download time will not be to long. How fast is your execution
time?
These are for speeding up a page only, and not to be used in every case.
What can slow it down: CF Includes, lots of HTML, over modularity.
What can speed it up: Sticking all code for a high impact page into one
page. Caching queries. Limiting logic and variables. Less graphics. Less
HTML tables. Not calling cookies or client side variables. Less
JavaScript. Maintaining DB connection. A table structure specifically
written for the type of search their doing. Indexes.
>From CF 4.5 debugging:
Execution time = startup, parsing, & shutdown.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Karen Harker
Sent: Friday, January 19, 2001 12:52 PM
To: [EMAIL PROTECTED]
Subject: Cold Fusion Performance issues
I am trying to improve the performance of our most popular site for our
primary clients - a list of electronic journals (ejournals). Currently,
from on-campus (therefore, using campus internet connections, which are very
fast), the load time for the largest listings (for titles beginning with A
or J) averages 9 seconds. This is not very good. But it gets much worse
from off-campus (upwards of a minute).
The code is moderately complex (several conditionals determine exactly what
about each title is displayed) and heavily commented. There are also tiny
images that are displayed for each title. But I think the problem may simply
be the sheer number of records in the results set: for the A's there are 323
titles, and the J's there are 604. Multiply the execution of the code by the
number of titles, and it is no surprise it takes a while to load.
I'm trying to create potential solutions, but most of these ideas seem like
they may be too confusing to our clients. After some usability tests, we
have found that our clients (academic medical faculty, students and staff)
do not mind scrolling through a long list as much as they mind having
difficulties finding links that are "hidden" on separate pages. And the
alphabet browsing is still the most common way our clients find titles,
despite the long load time.
However, we would like to reduce the load time as much as possible. What
behind-the-scenes, technical tricks can I do to improve this?
Another thing - using "debug" mode, I get the "Execution time" in
milleseconds. However, when I use a hand-held timer, the average load time
is 3x the "Execution" time. What does "execution" time measure? Does the
difference mean that the problem is elsewhere?
Thanks for any help you can give me.
Karen R. Harker, MLS
UT Southwestern Medical Library
5323 Harry Hines Blvd.
Dallas, TX 75390-9049
214-648-1698
http://www.swmed.edu/library/
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
|
Thanks for helping me out. Your suggestions were very helpful.
Interestingly, the improvement I implemented that made the most difference
was removing a call to an image to be displayed for each title. Although
the image is tiny (both physically & file-size wise), removing it reduced
the actual load times by 25%.
The other two changes I made (de-modularizing the processing file and
indexing the table) reduced the execution time slightly (down to about 2800-3000
milliseconds), but the load time was only negligibly reduced.
Adding "next N" or range methods would not effectively reduce the overall
time it takes for users to get to the title(s) they want. While they are
"browsing", they are looking for something specific. They are probably only
"browsing" through the letters because either they don't know the exact title
(although I do provide a keyword search) or they are used to that method because
this is how they use our print collection (our hard-copy journals are on shelves
in alphabetical order).
Thanks, again, for your help.
Karen
>>> [EMAIL PROTECTED] 1/19/01 2:23:21 PM >>> Karen: 3 things to examine for performance: 1st look at your execution time via your debug options. These measurements are the "Processing" time the CF Application server needs to complete the request. How many milliseconds does this template need ? 500, 1000, 5000, more ? Something over 2000 is starting to get too high and if it is over 5000 pretty unacceptable outside of an intranet. If your numbers are high, look at your queries and complexity of statements. This CF measurement has nothing to do with the time it takes the webserver to serve up the page and for the client to download and display the result set in their browser. That would be bandwidth, client, etc. 2) Take a look at the page properties, does the weight exceed 70,000k ? is the whole list wrapped in a table. You might look at displaying N records at a time on the screen and then a 1,2,3,... click buttons at the bottom a-la-alta vista that you can view 20-30 rows at a time; this will greatly reduce the page size; because 300 or 600 rows of anything, even just a 50 character display of each row would be up to 30,000 characters if there are 600 rows and if you displayed 30 rows at a time 1,500 characters. That is a BIG difference in the page size. 3) You might also look at your CF settings in the CF Administrator regarding template size / caching / processes. And make sure that you enable Enforce Strict Attribute Validation (Checked) When checked, strict attribute validation rules will be used. Extraneous attributes will not be allowed for any tags in CFML. When not checked, irrelevant attributes may be passed to CFML tags. Strict attribute validation improves template execution time and allows for the prevention of many CFML coding errors. Bob Coalter At 01:33 PM 1/19/01 -0600, you wrote:
|
