Further work, and I've set BoltWire to first check that cronMode is active, and second, if active, to see if $now is > cronLast + cronCheck before any call to site.cron is even initiated. All 3 vars are set in site.config, though cronLast is updated dynamically, and should be left as blank initially.
This seems to minimimze the potential processing involved about as far as will be possible. We'll see if it helps the cpu errors. I've just uploaded to BoltWire. I'm inclined to change the stopwatch system slightly, so that it is turned on automatically when error reporting is enabled--rather than requiring a separate variable. Any thoughts? Cheers, Dan On Mon, Dec 8, 2008 at 11:55 AM, The Editor <[EMAIL PROTECTED]> wrote: > I've been digging a bit into the excessive CPU usage issue and have > come up with a few insights. > > 1) First, there seems to have been some problems with the stopwatch > function not quite calculating times. I've fixed that a bit. > > 2) To get the stop watch function to work on things like indexing and > cron, I had to rework how the engine script generated it's final > output. Finally managed to get that working right. > > 3) Now with this new information, I was able to notice the cron call > was taking a fair bit of time, even when turned off. (It wouldn't do > any processes, but it would call site.cron, load the whole page, and > then ignore all the cron jobs because it was turned off. Better to > never bother with any of that if turned off, right? And if there were > cron jobs (I didn't have any set up), it would take even more time to > check them all) So I added a simple check to engine.php to correct > that problem. Now the pseudo cron is called only when turned > on--which is what we want. > > 4) I think the reason this has come up recently, is I often turn off > the pseudo cron function in engine.php when I'm doing debugging to get > my system messages back -- and then forget to reenable it when I > release the upgrade. Meaning sometimes you have it working, sometimes > you don't. (I'm sorry about that.) I've been checking that the last > few releases--and been more consistent, so that may be why we are > noticing the problem more than before. > > 5) I'm not sure this is the full solution, but it is a start and > should help. The cron call--even when nothing was happening took about > 40% of the cpu processing time. It didn't slow page performance, > because it takes place after the page is flushed out to the browser. > But it does contribute to the kind of stuff we've been noticing here > and there. And that's in a situation where there are no cron jobs to > even test for. > > 6) A much more complete solution might be to create some kind of > temporary cron.timestamp page/or a site.config value that could be > read, very quickly, and only run your cron jobs when a specified > amount of time has elapsed. This way, if you have cron turned on, and > multiple users browsing your site, the cron call is only made once > every so many seconds or minutes. I'll tinker with this a bit and see > if we can't get much better performance when using cron. Shouldn't be > too hard. > > I'll keep you posted > > Cheers, > Dan > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
