in reply to Best perl environment for mySQL server?

The last time I looked, FastCGI was essentially not an option on Win32. If you have an experienced Windows C hacker, you may be able to get it to work. Otherwise, look elsewhere.

There are two good options. First, ActiveState makes something called PerlEx which is essentially mod_perl for IIS. It is not as widely used, and it is a commercial product without source code, but it will probably work. The other option is mod_perl 2, which should also work. The path for migrating from CGI is fairly simple, using ModPerl::Registry.

The biggest potential problem with either of these solutions is that they will be multi-threaded on Win32, and it is possible that some of the XS modules you are using might not be thread safe. I'd suggest giving it a try and seeing how far you can get. Then ask for help if you get stuck.

The speed gains from either of these will be huge, so it's certainly worth your time to try it. Good luck!

  • Comment on Re: Best perl environment for mySQL server?

Replies are listed 'Best First'.
Re: Re: Best perl environment for mySQL server?
by Anonymous Monk on Dec 24, 2003 at 22:46 UTC
    The more I looked, the more I didn't think I was seeing any new FastCGI info. I saw some info on ModPerl::Registry and a lot of info on porting issues. It looks like work, but not too bad.

    The biggest issue is globals and local variables. Most of the globals are in a config file that's required. But I wonder, what's the blessed way of referencing a file of global config variables in a squeaky, clean way?

    Thanks.

      In mod_perl, global variables keep their values over multiple requests, but that might not be a problem in configuration variables, because they usually do not change their values after initialisation.

      I usually reference global 'constant' variables like:

      # create global config package MyConfig; our $OPTION = 'option_value'; # and in some other file do: use MyConfig; print $MyConfig::OPTION;

      I'm not 100% sure about this setup, though. On the one hand, accessing global variables with a package prefix makes for hard to spot spelling errors, on the other you can interpolate variables much more easily than constants created by use constant.

      My 'reasonably paranoid' solution is to use warnings FATAL => 'all'; to intercept usage of undefined variables (and to force myself not to clog my error logs with useless warnings).

      Local (not my) variables can be a problem in general and I would suggest not using them unless you really, really have to (like temporarily replacing a special global). I'm not aware of specific mod_perl problems with them, though. (But I might have missed something, as I said, I try to avoid using local variables at all).

      HTH,
      Joost

      There is documentation on this here.