I think that on all these things, moderation and compromise is the key. You can spend thousands of your clients dollars tweaking performance out of every last action on the site, but it's not always warranted.
For example, on a page that's key to the site, the central, most visited page in the site, then milliseconds shaved here or there are probably worth it. On another page, that might be used once or twice a week, saving whole seconds off the processing time might not be worth the time and money to speed them up. Similarly, you can spend a LOT of time fiddling about with getting RAM usage down by using other techniques than OO. But there are a lot of advantages to using OO, and if you arent in danger of starving other parts of the application of RAM, it's not a bad compromise to allow RAM to be used up by users' CFCS in the sesson scope - AS LONG as you dont have so many concurrent user sessons that you hog RAM needed by other parts of the Appl. For example if you expect to have 20 concurrent user sessions, putting userbean.cfcs into session scope has less impact on the rest of the app than if you have 500 concurrent user sessions. But even then, whether that degrades the performance of the application or not depends on other factors as well, for example how much total RAM you have, and what else is going on with that machine - does it also run a mail server? database server? etc etc. What I'm saying is, you can worry and fret about all these issues, but whether it's worth the time and trouble depends on a lot of factors. In a high-traffic site, nearly all of it is worth it. On a small business, very low traffic site, you can do almost anything and it wont matter a damn to the overall performance of your server. What counts in the end, is getting the job done on time, and making sure it works. Poor architecture might bring your server to its knees, (in which case you better spend whatever time it takes to get all the performance tweaks you can) or it might not make any difference (in which case, go ahead, launch the site cfcs in RAM or not and go to the beach, happy in the knowledge you have produced another working site). In my experience, there is no such thing as a perfect site. You are DEFINITELY going to launch a site with things that could be done better. Everyone does. What you have to do is compromise between the aims and goals of the site owner, the standards and specs of perfect architecture, and the time and money you have available to spend on getting everything right. Get it as right as you can, working as well as you can, then move on. Don't worry about it. That's not to say I advocate taking a shoddy approach. But sometimes getting ease of maintenance and speedy development is worth it, even if it degrades performance of the site slightly. Cheers Mike Kear Windsor, NSW, Australia Adobe Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month On 4/9/07, Jaime Metcher <[EMAIL PROTECTED]> wrote: > It's looking pretty bleak - we can't store CFCs in session because they take > too much memory, and we can't instantiate per request because it takes too > much CPU. Thank heavens for procedural programming. ;) > > Seriously, though, I have high hopes of CF8 in this respect. We have the > language features for OO, but trying to think OO with one eye on the > performance monitor is just a bit too schizoid for me. Now it's up to Adobe > to tune the app server. Failing that, you can always write your model in > Java. > > Jaime Metcher > > > - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Deploy Web Applications Quickly across the enterprise with ColdFusion MX7 & Flex 2 Free Trial http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:274815 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
