No, I just mean having an image tag <IMG src...>. The files themselves are less than 1KB each, but multiply this by 300 or 600 times, and I've added 300-600KB to the file size. Also, I think the time it takes to call this image 300-600 times could add to the load time. Karen >>> [EMAIL PROTECTED] 1/19/01 3:39:13 PM >>> Karen, What do you mean "call to an image" is this a CFINCLUDE? Please clarify. Kelley V. Kasperbauer Digitaris Technologies, Inc. [EMAIL PROTECTED] 972-690-4131 ext.104 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Karen Harker > Sent: Friday, January 19, 2001 3:19 PM > To: [EMAIL PROTECTED] > Subject: RE: Cold Fusion Performance issues > > > 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 > ------------------------------------------------------------------------- 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
|
No, I just mean having an image tag <IMG src...>.
The files themselves are less than 1KB each, but multiply this by 300 or
600 times, and I've added 300-600KB to the file size. Also, I think the
time it takes to call this image 300-600 times could add to the load time.
Karen
>>> [EMAIL PROTECTED] 1/19/01 3:39:13 PM >>> Karen, What do you mean "call to an image" is this a CFINCLUDE? Please clarify. Kelley V. Kasperbauer Digitaris Technologies, Inc. [EMAIL PROTECTED] 972-690-4131 ext.104 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Karen Harker > Sent: Friday, January 19, 2001 3:19 PM > To: [EMAIL PROTECTED] > Subject: RE: Cold Fusion Performance issues > > > 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 > ------------------------------------------------------------------------- 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 |
