Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You've got a pretty big vested interest in Apache/mod_perl, and while I did previously, I don't any more. I have to be honest in that writing AxKit2 this way was mostly because I was curious as to how good it could be. I know pretty much for a fact that it'll be slower than mod_perl, because Apache2's connection handling and perl integration is very well built and designed.

    However now AxKit2 is built I find it much easier to hack on than mod_perl, and not just because I know the internals. Adding a new conf
    • Adding config stuff was pretty bad in mod_perl 1. It's supposedly easy in mod_perl 2, but I've never wanted to add a config directive so it's not something I pay attention to. I really don't use any of the Perl config stuff in mod_perl at all. It just doesn't appeal to me.

      Profiling, quick restarts -- well, they work for me in mod_perl. (This reminds me of working at a place that used IBM WebSphere, where restarting the dev tools to pick up a code change took 10 minutes! What a pig that thing was.)

      You

      • I think partly people don't add custom config in mod_perl apps because they're hard (still non-trivial in mod_perl2 - that was one of my stumbling blocks in doing a straight AxKit port to mp2), and partly because they are satisfied with "PerlSetVar" which I never really liked as it didn't seem to cope with multivalues terribly well, and partly because none of the introductory docs cover them. I've tried to make sure my introductory docs jump right into them because they're terribly useful.

        Another option I'm thinking about is if I can emulate the mod_perl API enough then I might be able to make some (but probably not all) auth plugins just drop right in.

        But that's for another release a bit later I think :-)

        As for "Profiling, quick restarts -- well, they work for me in mod_perl" -- I have to be fair that I haven't used mod_perl 2 much, but I still find the whole apache startup time to be way too slow. With AxKit2::Test we can hook right into the startup process with a pipe() so that we know when it has started (and if it has failed) a lot faster, meaning the tests get going a lot faster.

        Regarding profiling: I'm not sure whether it's better or not, but under AxKit2 you know exactly how much of your time is spent processing the request/response as well as is spent in your application code. Obviously you trust Apache/mod_perl2 to do that very quickly so it's not a huge issue for you, but I kind of like the fact that all that info is available to me.

        I'd also urge you to play with it a bit - you might actually find you like it :-)