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

Hi Fellow Monks

I am currently trying out FastCGI on IIS and have some basic questions that I hope that some of you can shed some light on.

First a bit little bit of background. I am working on a web application that have existed for something like 10 years. It is written as a pure CGI application. Most of the application use CGI::Application, but some older parts are just plain old CGI .pl script that print directly to STDOUT. In total the application contains about 100.000 lines of Perl code in addition to templates, Javascript, etc. Clients buying the application can either have it hosted on our servers or we can install it on-site. Our own servers run IIS (not going to change) and all our clients with on-site installs have IIS as well.

In general we have no problems with running the application using pure CGI except of course speed. The application is not extremely slow, taking perhaps 1-2 seconds to answer a typical request, but if I could drop that to for instance 0.5 seconds for a typical request I think it would greatly improve the application.

So in an attempt to speed up the application I thought I could try to run it under FastCGI. I have now tried running the application using the FastCGI extension for IIS 5.1 from Microsoft and tried out both CGI::Fast and FCGI::IIS. I have partially gotten the application to run with a significant speed boost, but there seems that there are a number of tricky bugs that need to be fixed to get it to work flawlessly. Some of the bugs I have experinced are:

So before I spend any more time tracking down these bugs and others that will undoubtly crop up I have a few questions I hope some of you can answer.

  1. Does anyone have experience with getting a pure CGI application to run under FastCGI? Was it a large effort? What type of changes where required? Any recommendations for how to proceed with the changes?
  2. The application still needs to work under normal CGI as we probably will have problems getting the FastCGI extension installed on clients servers. Is it hard to get an application to work with both CGI and FastCGI at the same time?
  3. Are anyone using the FastCGI extension from Microsoft or are the other alternatives that are better?
  4. When running under CGI $FindBin::Bin contains that path of the executed CGI script. As the libraries are placed relatively to the scripts this is needed to set @INC correctly. Under FastCGI $FindBin::Bin contains the path to perl.exe making it harder to set @INC correctly. Is it possible to work around this somehow or is it something I just have to live with?

Any help and/or recommendations are greatly appreciated.

- oyse

  • Comment on Getting pure CGI application to run under FastCGI on IIS

Replies are listed 'Best First'.
Re: Getting pure CGI application to run under FastCGI on IIS
by locked_user sundialsvc4 (Abbot) on Feb 04, 2009 at 22:25 UTC

    Hmmmmm....

    First of all, I am of the opinion that “what you are setting out to do, is very worthy to do, and that it surely needs to be done.” I am also of the opinion that it can be done.

    However, both you and your boss (and the business owners) need to understand that this will represent a very fundamental change in the environment in which this “huge, ugly, and mission critical” application expects to run. A whole lot of bugs and deficiencies that have been successfully “glossed over” for all of these ten years are going to come bubbling-up to the surface. And, they will howl. It is not realistic to expect that you can give a positive completion-date ... or cost ... at this juncture. But there's a business justification to do it, regardless. It will pay off.

    (“Trust me...”)  ...  (“I said, trust me, dammit!”)  ... (“Can you spell m-o-n-s-t-e-r--d-o-t--c-o-m?”)

    :-D

    In my view, “Windows and IIS have nothing to do with it.” You would surely encounter these problems anywhere. Therefore, my recommendation would be ... to perservere.

    You should first obtain management buy-in ... and I feel that it ought to be summarily granted ... that “we are going to do this.” Then, having obtained that papal blessing, approach the task very systematically. Flush out all of the issues that you can find, and explicitly enumerate them. Rank them into priority and then start shooting them down. One by one. Your “mission-critical monster” will morph into a much better monster, and hence it will be money well-spent. But you will lose some hair-follicles along the way...

      Thanks. This was exactly the kind of feedback I was looking for. I wish you could have said that this would be trivial, but you can't get everything :)

      I also think that this conversion is something that probably has to be done, but management buy-in is going to be difficult. We have a limited amount of resources so arguing for using good chunk of our available time on this is going to be difficult. I will probably try to get it to work more or less flawlessly on a small and recently implemented part of the application as a proof of concept. Then I can use that to showcase how much more responsive the application feels and convince them to do the conversion for the rest of the application as well. Given that I can actually get it to work of course.

      BTW I am still interested to hear others experience with doing this type of conversion and on getting it to work both under CGI and FastCGI.

        (Shrug...)   So you have to make a compelling business-case for it. And then they have to decide if they want to spend the money to do it now. Or, just as likely, they may come back to you and ask how they can do some worthwhile piece of it.

        You of course absolutely must prove the engineering viability of the project first. And, you must establish that there is an acceptable amount of business risk, because the risk of this change is quite-substantial and “they can always throw more silicon at it.”

        If, and only if, both the viability and the risk-management of the proposition can be established (in the eyes of a non-technical devil's advocate), and you can come up with a believable budget and timeline (with “escape paths” that can be taken in the event of an unforseen snag), then “this is a worthy project that very-likely ought to be done.” But you're gonna be put in the dock for this one, and grilled heavily. Expect that.

        Fair warning:   the business decision could go either way. The technical risk scares me, even from this distance. It's a big gamble if it succeeds, and a big fat “sunk cost” if it doesn't. And all of that is no reflection whatsoever upon you.

        In fact, I think that I would spend some time play-acting, taking the devil's advocate position yourself and arguing-like-hell that:   “It would be absolutely insane to think about even touching that thing! This is our product! It's what stands between us and the unemployment line! You must be out of your mind!” Think of every possible thing that the company could do “instead,” and argue every one of those alternatives mightily. Because that's exactly what the managers are going to be wrestling with, too.

        Try to think of every angle. You say, for instance, that “we can host it, or we can install it on a customer site.” Uh oh... How much are all those installs gonna cost? What if a customer doesn't want to install it? What if half of them do and half of them don't? How certain are we that everyone who wants to install it will succeed in doing so? What if an obscure technical problem crops up and suddenly a happy customer turns into an unhappy one? What sort of test-plan and rollout-plan will be needed to prove that it's as stable as what we have now? Why shouldn't we let a 100,000-line sleeping dog lie? Where's that ROI now? Still there? “Good...! Is it ready yet?” :-D

Re: Getting pure CGI application to run under FastCGI on IIS
by perrin (Chancellor) on Feb 04, 2009 at 21:22 UTC
    When running in a persistent environment like FastCGI, you basically have to make the same changes you would for mod_perl. This means watching out for globals and closures. There's good introductory material on http://perl.apache.org/ that can help you with this. If you show some code, or at least the error messages, we might be able to help with the issues you're having with the CGI object and query parameters.

      I will take a look at the mod_perl documentation. Thanks for the tip.

      For the specific issues I have had with the CGI object and the CGI parameters, I think it would be easier to post each of them in separate thread if I decide to do the conversion. That would make them easier to find using Search later as well.

      Now I am more interested in getting an idea of the scope of the effort of getting a CGI application to run under FastCGI and if there are important issues to keep in mind (in addition to the globals and the closures that you already mentioned), if running FastCGI on IIS is common and if it is possible to have a application run but under CGI and FastCGI without doing too much work to keep the application running under both environments.

Re: Getting pure CGI application to run under FastCGI on IIS
by zentara (Cardinal) on Feb 05, 2009 at 15:00 UTC
    Have you googled for "IIs server fastcgi configuration Perl" ? From my testing of FastCGI on linux/apache, you need to setup FastCGI in your server configuration file....things like what directory they run in, how many spares to have ready, whether to reuse or not, etc.

    It's more involved than just putting "use FastCGI;" at the top of your script.

    Here is the way it is done with the Apache server ... FastCGI Apache configuration" I'm sure there is something similar for IIS.

    If you do get it accomplished, it would be nice of you to write a little setup-tutorial for it, to save others time.


    I'm not really a human, but I play one on earth Remember How Lucky You Are

      Getting the most basic FastCGI setup to work on IIS was not that difficult. How to get the basic configuration to work is described here. It is going from this basic setup to running our application under FastCGI that seems to be quite tricky.