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

We've been using W2K, IIS and ActiveState perl for a number of years. That's worked well for us generally, but the number of concurrent processors and multiple db connections is now causing periodic problems. So we've planning to go to Apache and mod_perl or fast_cgi to get persistent db connections and avoid the multiple perl processes as well as knock up the performance. This effort will require a fair amount of work as there is tons of code and it'll all need to be reviewed and much of it modified to work right in a persistent environment.

The server is a dual CPU machine that will likely by running Win2003. Given that starting point which packages would you choose to use? Performance in a high volume production environment is a primary consideration along with stability. Ease of porting old code is also important.

I've been seeing some information about Indigoperl. What are the pros and cons versus ActiveState?

My impression from a few articles is that the current mod_perl doesn't handle multiple processors in Windows but that 2.0 does, but isn't fully stable? Is fast_cgi a better alternative for a dual CPU Windows machine or is my impression wrong?

Finally, is one DBI package better than another? We've been using whatever is linked from the mySQL site currently.

Thanks

  • Comment on Best perl environment for mySQL server?

Replies are listed 'Best First'.
Re: Best perl environment for mySQL server?
by perrin (Chancellor) on Dec 24, 2003 at 20:26 UTC
    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!

[reply]
      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.

[reply]
        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;

        [download]

        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

        "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
[d/l]
[select]
        There is documentation on this here.
[reply]
Re: Best perl environment for mySQL server?
by jZed (Prior) on Dec 24, 2003 at 18:34 UTC
    is one DBI package better than another? We've been using whatever is linked from the mySQL site currently.
    If you've settled on MySQL, then DBD::mysql is the correct tool. There's a DBD::mysqlPP, but that's just for places where the full article can't be installed. If you're thinking of other backends, then the DBD for most backends is pretty clear cut (DBD::Pg for postgreSQL, etc.)
[reply]
Re: Best perl environment for mySQL server?
by {NULE} (Hermit) on Dec 24, 2003 at 19:46 UTC
    Hi,

    I can't comment on this with respect to windows, but I've been using mod_perl 1.99_09 (Apache 2.0.47/Solaris 2.9/MySQL 4.0.15) at work for quite a while without any problems. (Before anyone jumps on me for not being quite up to date - these servers are on a private network, so security isn't a huge concern.) Performance is good, though my load is few, but relatively intense queries, and your mileage may vary. My understanding is that Apache 2 is worlds better than 1.x on Windows and if you go that route, you have to use mod_perl 2.0 (well, 1.99_12 as of this writing).

    Good luck

    {NULE}
    --
    http://www.nule.org

[reply]
      Thanks, we're on mySQL 4.0.16 and have loaded 17 on the new server. It seems stable and performs as well or a little better. Have you run into any bugs with mod_perl 2 that are problems?
[reply]
Re: Best perl environment for mySQL server?
by William G. Davis (Friar) on Dec 24, 2003 at 22:58 UTC

    As was already mentioned, DBD::mysql, which is what your probably using, is the preferred way to interact with MySQL from Perl. In a persistent mod_perl environment you should look into Apache::DBI to enable persistent database connections for each HTTPd child process (I think it even comes with DBI or libapreq--one or the other). As for whether you should use ActivePerl or IndigoPerl, well, I can't comment on the latter, but I have used ActivePerl before (an older 5.6.1 version) and I can honestly say that it's a stable, polished, production-level port of Perl to non-Unix systems. It's the preferred port of Perl to Windows even over the more official CPAN Windows distros, and ActiveState maintains a plethora of documentation, FAQs, and mailing lists to help you out.

    See this node here for a (short) discussion on the merits of both ports.

[reply]

Back to Seekers of Perl Wisdom