> > Instantiation is expensive, so you want to avoid it as part of request > > handling. > > I think that's overstating the issue rather dramatically
Yeah, I know. Ryan asked about pooling, so I was explaining the impetus and the how, with no regard to the "should I/shouldn't I". Oversight on my part. > This is way complex for most apps - I really think it's overkill and I > would not recommend it as a 'default' approach. I whole-heartedly agree. I mentioned that pooling should be reserved only for load testing confirmed bottlenecks in my first email, and should have reiterated in my second. I, for one, have never had a need to implement a CFC pool, and while I can't say I work on massive apps, they're of decent size with decent load. Still way cheaper to tune some SQL, add some caching, or even buy another box than it would be for the improvements pooling would bring. At least with the architecture we're currently using. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
