Barry & Mark - I think this will be very useful. I've got it down to 6 seconds (with the db query cached), but it's still smashing the CPU.
Each iteration of the loop itself is negligible (cftimer is reporting between 0-32ms). I think it's just that there's too many records. Each one needs to be processed - various links placed on them via a custom tag, etc. I think a combo of a scheduled task with a thread wait() may do the job...will keep you posted! Andrew. On 2 February 2010 17:29, Mark Mandel <mark.man...@gmail.com> wrote: > For some more reading, there is an article I posted about managing selfish > threads in CF: > http://www.compoundtheory.com/?action=displayPost&ID=373 > > This is generally for situations where you can't optimise any further, or > is something that is just simply going to be expensive no matter what you > do. > > Mark > > > On Tue, Feb 2, 2010 at 5:11 PM, BarryC <barrychester...@gmail.com> wrote: > >> If you're stumped for optimisation of a long running task, then having >> a scheduled task is a great idea, but even when the scheduled task >> runs, unless it's optimised it could still cause a performance hit. >> An idea might be to put a 'thread wait ()' in your loop to allow other >> things to run otherwise it will try and run the loop as quickly as >> possible. >> Coldfusion 8 has a built in tag for that, for Coldfusion 7 or earlier >> you need to call the a java thread function which is straight forward >> but you need to google to see how to do it. >> Depending on your environment, any heavy tasks are always worth >> shifting off your production environment onto a separate one (and push >> the result to production). Not always feasible tho :) >> >> Barry >> >> On Feb 2, 4:26 pm, "charlie arehart" <charlie_li...@carehart.org> >> wrote: >> > Andrew, does that "fair bit of nested cflooping" show a CFQUERY buried >> > within that loop? Where it's taking data from the one query and using it >> to >> > do another? If so, that's a classic case where perhaps a join would >> solve >> > the problem. CFML developers often fall into a trap of having CF do work >> > that the DB should be doing. If the code you're wrangling with is doing >> the >> > above, it may be good value to evaluate the prospects of doing a join >> > (whether a traditional inner one, or the less well known outer-which is >> > another reason some drop to doing nested CFQUERYs if they don't >> understand >> > it). >> > >> > Also, as for your comments on caching and batch execution, those are all >> > worthy of consideration, sure, as long as you can manage it to be >> accurately >> > based on potential underlying data, as you say you are considering. >> There >> > are still other forms of caching, both built into CF and available >> > programmatically based on external libraries, that may be worth >> considering >> > if you don't solve the problem though optimization. >> > >> > /charlie >> > >> > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On >> Behalf >> > Of Andrew Myers >> > Sent: Monday, February 01, 2010 8:45 PM >> > To: cfaussie@googlegroups.com >> > Subject: Re: [cfaussie] Re: CF7 (and 8) High CPU usage on production box >> > >> > Update: >> > >> > This page generates a report from a query that itself takes about 29 >> seconds >> > (and I am not sure I can do a lot to improve that without getting some >> > cooperation from the guys who write the product I query out of, and that >> > isn't likely to happen quickly). >> > >> > I've been caching the page with a "roll your own" custom tag. The tag >> > checks a timestamp on the database and forces a regeneration whenever it >> is >> > necessary (it will change no more frequently than every 15 mins). >> > >> > What appears to be burning up the CPU is a fair bit of nested >> "cfloop'ing" >> > that's happening in the page. FR reports a heavy ColdFusion hit on the >> CPU >> > of my laptop when I run this page and nothing else at all is happening. >> >> > >> > Some thoughts: I can try and generate these reports via a batch job and >> only >> > make them available to the user once they're finalised. This might stop >> > requests queuing while the page generates? The fact that it seems to >> chew >> > CPU even when it's running in isolation seems to tell me it could be a >> waste >> > of time though. >> > >> > Which leads me to the next thought - does CF loop just really suck? I >> have >> > replaced it with a cfoutput in one part that I can easily do so and it >> seems >> > to have improved it slightly. I may well end up having to do a complete >> > rework I think. >> > >> > And that's assuming this is the only problem, and I doubt it is... >> >> -- >> You received this message because you are subscribed to the Google Groups >> "cfaussie" group. >> To post to this group, send email to cfaus...@googlegroups.com. >> To unsubscribe from this group, send email to >> cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/cfaussie?hl=en. >> >> > > > -- > E: mark.man...@gmail.com > T: http://www.twitter.com/neurotic > W: www.compoundtheory.com > > Hands-on ColdFusion ORM Training @ cf.Objective() 2010 > www.ColdFusionOrmTraining.com/ > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
