I agree. Upwards of 90% of the issues with performance I've ever seen with a CF site are due to poor SQL methods. Things like SELECT *, or looping over one query result and performing another query in that loop instead of joining the two tables in one query. In Oracle, the order with which you reference tables and make comparisons in the WHERE clause has a significant impact on performance. (Not so in SQL Server, apparently.) That's why we have a DBE on staff to support our CF guys. (And the other back-end legacy stuff that's far away from CF.)
The BIG CF problem I'm seeing now is in working in this site with two-year-old code, written primarily by inexperienced CF coders, has terrible maintainability and readability. It's like the concept of code reuse was foreign to them. (Curse the Copy-and-Paste function in Windows!) > -----Original Message----- > From: Adrian Lynch [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 16, 2002 7:04 AM > To: CF-Talk > Subject: RE: Best Practices > > > Well it is said that a CFer's weak point is SQL > > Ade > > -----Original Message----- > From: Jon Hall [mailto:[EMAIL PROTECTED]] > Sent: 16 August 2002 11:39 > To: CF-Talk > Subject: Re: Best Practices > > > How much CPU time does logic take up? Next to none. The only way we > can get any kind of metric on logic speed is to loop over it 1000 > times. > Every single thing that is performance sensitive in CF has to do with > accessing resources like file systems, databases, web services, etc. > We are not coding in assembler, or doing 3D math calculations, and > since we are using a RAD language, it would seem to me that the > emphasis would be on development time, not a millisecond or two. That > means to me that code readability is more important than optimization. > > Personally I get the job done and delivered, and if down the line, > performance becomes an issue, I generally tweak it for free within > reason. Performance stuff is the fun part, making money is the > necessary part to me. > People talk about a few milliseconds, but a browse through the dev > exchange will show that a lot of people are still looping over simple > queries that should be joined using SQL. > > An example, I recently increased performance by about 20x (no lie) > on a CF app that a customer paid $1000 for off the shelf. You would > think that someone who would sell an app for $1000 would use joins > properly, but no. Under load one page was taking nearly 30 seconds to > load, now takes .5ms under load, simply by using SQL properly. I > tweaked the logic bits as much as possible, even optimizing the > placement of cfoutputs, but for no mentionable gain. Once the SQL was > done properly, there was very little logic left to be done in CF > anyway. > > I'd be willing to bet that 99% of performance problems that exist in > CF apps today, have to do with accessing external resources, and not > from inefficient business logic routines. > > -- > jon > mailto:[EMAIL PROTECTED] > > Friday, August 16, 2002, 6:01:32 AM, you wrote: > > BH> When I was saying 1000 concurrent users I was not saying > 1000 users > BH> requesting a page at the same time. > BH> I was talking about 1000 active users (sessions) on the server. > > BH> Off course, caching and stored proc are an efficient way > to optimize you > BH> app. > BH> But usually, you can't cache everything and you can't > optimize code > logic > BH> (presentation or business logic) with stored procs (only > data access)... > > BH> Benoit > > > ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
