Well, you kind of have two questions there, but a single problem. I'm going to try a suggestion for solving your root problem, but it doesn't answer your question.
It is really worth it to duplicate the environment for fixes and development. Or, perhaps, the other way around - it's worth it to duplicate your development environment in your test environment (minus any "instrumentation" if applicable), and it's worth it to duplicate your test environment for your production environment if possible (in my company, we try to emulate customer production environments in our test environments, so it's again reversed, but if you can force your production environment to match a pre-determined environment, that reduces the amount of testing considerably!).
Note that I didn't use the word "easy" in there at all. It's still worth it. As you rightly point out, you want to figure out what's going on without making any changes to production code. That's smart. (Well, it should go without saying, but it doesn't - too many people try anyway - so that makes you smart.)
Note that it is completely plausible to create multiple servers on the same machine - one for development, one for test, and one for production (only the last one on standard port(s)). This may be the easiest way to duplicate the environment. You may have to restart your test and development server(s) frequently, but that should cause barely a hiccup on your production server on the same box as to its performance, and given that these are test servers (not stress test servers ;-}), their loads should be pretty much zero which should put nearly no strain on the box either. You can even put them into their own users when they drop privileges so they're even less likely to bump into each other.
It's worth it. When you can try "what-if" scenarios at will, that's worth it.
| [reply] |
Replicating your production environment for testing/debugging is not just a good idea. It is essential.
As for good ways of spying on your code - I wrote Sub::WrapPackages for just that reason. It is itself a wrapper around Hook::LexWrap, but wraps whole packages instead of individual subroutines. Writing the necessary wrapper to log subroutine entry/exit etc is left as an exercise for the reader. I have code for it, but haven't got round to CPANning it. Or you might write something similar using Aspect.
Also of interest may be Devel::Trace or Devel::TraceFuncs. I've not used the latter myself, and I don't know how mod_perl-friendly they are. | [reply] |