johnnywang has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I recently inherited a mod_perl project that is making my life pretty difficult. The main problem is that I can't easily duplicate the environment for fixes and development, so I have to resort to messing at the production environment directly. This leads to the general question of perl instrumentation.

I'm wondering whether it's possible to add, say tracing or other logging, to the production code without making any changes to code? In my java projects, I've played with some tools that can instrument the java bytecode via a custom class loader, thus adding logging information to a live system without code changes. I've looked at Hook::LexWrap, not really sure whether it's the right tool. Ideally I'd like to write some code which gets loaded when mod_perl starts, that will add tracing information to some specific modules or functions. Is that possible?

Replies are listed 'Best First'.
Re: perl instrumentation?
by Tanktalus (Canon) on Sep 15, 2005 at 01:15 UTC

    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.

Re: perl instrumentation?
by DrHyde (Prior) on Sep 15, 2005 at 09:37 UTC
    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.