Hello Tim, Interesting site you've got your hands on. With your talk of the files "compiling", I interpret that you're running CFMX, right? If so, read on:
For those search results pages you mentioned, any possibility that they could be written as static .html? Then you could either cffile action="read" them (no compilation that way) or point the browser directly to them. This sounds like the easier half of your problem; I think the user config part is a lot stickier. For the config files, a potential solution could be to write some scheduled code that cfincludes or cfhttp's the sets of config files, in order to get the first-time "compilation" parsing done on your own time instead of during page requests made by actual visitors. The scheduled code could be run during low-traffic hours to keep the server load level. Then when the user comes back the next day, they're up to speed because the scheduled scripts would ensure the cfm config files were already parsed. This approach is dependent upon a few factors in the site's architecture. It might not be viable if you answer "no" to any of these questions: (1) Are your config filesable to run standalone, or at least in the bare essentials of your application's environment? e.g. it would work best if they are pure cfsets and such that aren't dependent upon external data, but it could still work if the files used general app data like request.siteRoot (as opposed to using session variables). If you only need the generic variables, your scheduled code could just be part of the site application itself so when it runs it has all of that information available for the config file. (2) Does the user not need the config file the instant it is created? What would be ideal is if it only created the config file in the first session and then used the config file in later sessions to set up the user data. A less ideal but still workable situation is if the config file was not needed during the same request, but was needed on every subsequent request during the session. In that case, perhaps you could spawn another thread that parses the config file the moment it is created, in such a way that the server will not wait for it to parse but just continue on with the current request execution. Not sure how to best do this; I know cfexecute can do this if you set timeout="0", and there is a command-line utility to compile a cfm file. Actually, if you have a lot of access to your server you could do that scheduled script as a batch file or small executable that simply calls the CFMX command-line compiler. (3) Is the config file moderately permanent? If the file doesn't stick around for a few hours or a few days before getting modified then that scheduled compilation idea won't be very useful. Sounds like this config cfm file setup could have worked ok in CF 5 (there's still much better ways to accomplish what this design is trying to do - wddx, caching, etc), but yes in CFMX you're going to take massive performance hits for writing and cfincluding all kinds of dynamic .cfm files. On the bright side, I believe the red sky update includes a much faster parser. That in itself might help you out a lot :) Good luck! Mike Mertsock Alfred University Web Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
