On Thursday 14 October 2004 10:49 pm, victor wrote: > Hi malcolm, > >This might be stating the obvious, but have you run it under a profiler? ( > >Devel::Profiler::Apache is what I've been using). If it's a problem with > > the actual perl script, that should give you a good idea what part of the > > script is eating CPU. > I have that setup in the stage system, but not in the production. > These unusal problem we have have never been seen in our staging > platform, they are always kick started by condition we have never > expected. Or would you suggest I install that in production as well?
I've no idea what stability impact the profiler would have. It does impact CPU usage and memory consumption, it also generates potentially very large log files if it's running for any significant amount of time. You also have to shut the server down to finalise the profile logs (otherwise they tend to be difficult it not impossible to use). I don't have any stats on exactly how much the profiler overhead is (does anyone?) So I'd be very leary of using the profiler in production, especially if you have a high traffic site. If you have a situation that's not at all reproduceable in your testing environment, and you have a live environment where you can swap a webserver in and out of the configuration easily (or it doesn't matter if the server is down for a few minutes), then you might attempt it with caution, but you'd have to watch it - I certainly wouldn't leave it running by itself. Depending on your situation, the idea may give your collegues or manager fits. I'm working in situations where the server being down for five minutes wouldn't bother anyone much. That's probably a relatively rare occurance in a commerical situation. -- Everything that irritates us about others can lead us to an understanding of ourselves. - Carl Jung -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
