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

Hello all.

I'm trying to write a FastCGI dispatcher for a particular script, whose only task will be to insert some parameters I sent via HTTP GET into a DB. So I thought I could actually have the dispatcher itself connecting to a database to create a persistent connection, as opposed to having the running script (the one being ran through the dispatcher) doing it every time a request arrives, to help improving performance.

I looked around for some examples to get me started, and I found this, which seems nice and easy to modify. However, I can't seem to be able to pass the DB handler (I'm using DBI) to the underlying script running through it.

So my questions are:

1) is this a wise thing to do to increase performance?

2) if yes, how could I pass the handler to the script running through my dispatcher?

Thanks very much for any help.

  • Comment on Persistent MySQL connection handle on FastCGI dispatcher

Replies are listed 'Best First'.
Re: Persistent MySQL connection handle on FastCGI dispatcher
by jdtoronto (Prior) on Aug 15, 2006 at 00:11 UTC
    I don't think FASTCGI will do what you want. Have a look at Jifty::Script::Fastcgi form Jesse Vincent and see what he did. I note that he doesnt try to pass a handler through - FASTCGI apparently cannot even call your CGI with command line parameters.

    jdtoronto

      Thanks!

      I read this snippet in the page you mentioned:

      When you're ready to move up to something that can handle the increasing load your new world-changing application is generating, you'll need something a bit heavier-duty than the pure-perl Jifty standalone server. FastCGI is what you're looking for.

      So I might as well not even go down this path. I expect this script to be receiving no less than 800 requests per second, as it's part of another application that will perform logging over HTTP. Having the application in question connecting directly to the database isn't an option in this case.

      But thanks again anyway!