Add a few timers around each possible slow running process to try and narrow down what function is slowing the request and review them in the CBDebugger console.
I can’t quickly find the documentation for timer@cbdebugger. Here is a quick recap of how I have used it:
inject the timer into the handler, model, entity, etc.
Start and Stop the timer before and after suspect code
// Start the timer
debugTimer.start( "[Unique Timer Label Name Here]" );
/**** Existing Code/Function/Process/etc. ****/
// Stop the timer (must use exact same label used to start the timer)
debugTimer.stop( "[Unique Timer Label Name Here]" );
I can’t emphasise enough how often CBDebugger has made debugging quick and easy!
@gknight Check that you layoutParentLookup and viewParentLookup settings for the module are set to false. Those will check upwards of the module’s home for matching layouts and views.
25 seconds, though, does seem a crazy amount of time so the debugger might be necessary to determine what is taking so much time.
FusionReactor should be able to show you exactly what is going on in a matter of seconds. Either by pulling stack traces while the page is loading, or using the Profiler feature after the page has run.
Found the culprit, I was looping over the CF function isImageFile() (about 1,500 db results) with online images. I don’t even remember writing the code.