Evening all, We have under our control a site which makes a lot of use of dynamically created CFM files for information such as user config files etc -- when a user first logs in to the site a config file is created for them with details such as username, access rights etc which can then be quickly <cfinclude>'d without needing a call to the database every time.
The same mechanism is also used for pages of search results so that all results are written to separate CFM files (page1.cfm, page2.cfm etc, all under a directory unique to the user making the search). Oh BTW, we didn't design the application, we're just trying to work out what's going on! Doing this is OK under the principle that it negates the need to go to the DB every time and that once the config file etc is compiled it's super fast. However, recently we've encountered a problem that many of the scripts that perform the <cfinclude> are timing out. For example, on a site with not-heavy traffic, we shouldn't be getting 118 requests timed out (timeout set to 30 seconds) in approximately 8 hours... All we can think of is that there is an issue somewhere that after a file has been written and then an attempt to <cfinclude> it is made that the compilation of the file takes too long. Unfortunately there's no pattern as to _when_ something will go wrong, just that (by way of a stack trace when the requests are queueing up) we can see that all apparently "stalled" processes are on <cfinclude> lines to dynamically created files. You can see what happens by way of the cfstat output here: Pg/Sec DB/Sec CP/Sec Reqs Reqs Reqs AvgQ AvgReq AvgDB Bytes Bytes Now Hi Now Hi Now Hi Q'ed Run'g TO'ed Time Time Time In/Sec Out/Sec 1 4 1 14 -1 -1 0 1 98 0 22 1 629 947 0 4 0 14 -1 -1 0 6 98 0 22 13 315 0 0 4 0 14 -1 -1 2 10 98 0 2343 51 605 2240 0 4 1 14 -1 -1 14 10 98 3594 14714 13 300 1398 0 4 0 14 -1 -1 17 10 98 3594 14714 13 184 0 3 4 8 14 -1 -1 0 4 105 4 385 0 966 7751 0 4 2 14 -1 -1 0 1 105 1 13742 52 112 2701 1 4 2 14 -1 -1 0 0 106 0 7572 6 301 3019 As you can see, everything works OK until running, then queued, requests start climbing until (in the above) 7 scripts time out and everything gets flushed through. Initially we thought it was a problem with some named locks we were using, but that's been ruled out them being removed and the problem still persisting! If anyone could point me in any direction at all (except _that_ one!) then I'd be most greatful! Cheers m'dears... Tim. ------------------------------------------------------- RAWNET LTD - Internet, New Media and ebusiness Gurus. Visit our new website at http://www.rawnet.com for more information about our company, or call us free anytime on 0800 294 24 24. ------------------------------------------------------- Tim Blair Web Application Engineer, Rawnet Limited Direct Phone : +44 (0) 1344 393 441 Switchboard : +44 (0) 1344 393 040 ------------------------------------------------------- This message may contain information which is legally privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any unauthorised disclosure, copying, distribution or use of this information is strictly prohibited. Such notification notwithstanding, any comments, opinions, information or conclusions expressed in this message are those of the originator, not of rawnet limited, unless otherwise explicitly and independently indicated by an authorised representative of rawnet limited. ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
