Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

lighter alternative to

by perrin (Chancellor)
on Aug 29, 2002 at 18:41 UTC ( [id://193850] : perlquestion . print w/replies, xml ) Need Help??

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

I'm helping out with a project that is using Perl from server-side includes on an NT box running IIS. (Yes, it sounds crazy to me too.) The project has hit some performance problems, and it seems to be partly because of the time spent compiling on every request. I'm looking at replacing with an alternative, less bloated module.

The script only needs to parse form variables, parse cookies, and determine its URL. It looks like CGI_Lite can do all that. Is that the preferred replacement for these days, or is there something else I should be looking at? (Remember, it has to work on IIS.)

Replies are listed 'Best First'.
Re: lighter alternative to
by Ovid (Cardinal) on Aug 29, 2002 at 19:13 UTC
      Thanks. I don't suppose anyone has ever compared CGI::Simple to CGI_Lite?

      The server is using the ISAPI Perl DLL. Taint-checking? I wish. This is someone else's legacy code, and it doesn't even use strict. I'm hacking out my own little island of clean code in the middle of it, with hopes of eventually expanding to conquer the rest.

        I'm not aware of any comparisons. I like CGI::Simple because it's a drop-in replacement. Converting your code will be ridiculously simple. Since CGI_Lite does not share the same interface you have a longer conversion time and a greater likelyhood of bugs.

        One feature of CGI_Lite that you have to contend with is the setting of the OS type to determine line endings with file uploads. If someone simply hardcodes the OS in there, you now have non-portable code.

        I just took a look at the CGI_Lite code and spotted a bug. The separator for query strings is defined in the module as an ampersand. It should also support a semi-colon as that's the recommended separator -- though I confess that few use it.

        I also noticed that the CGI_Lite::is_dangerous() method skips the null byte. Oh wait! It's not even a method, it's a function, so you can't subclass it. If you need to subclass it (though it sounds like you don't), you'd have to reimplement all of the functions in there that don't pass $self as the first argument.

        All in all, CGI_Lite looks like a nice module, but I see some issues with it that could stand some fixing.


        Update: I just noticed that the is_dangerous function also explicitly returns a zero for false. While I think it's clear that this is to be called in a scalar or boolean contect, if someone were to accidentally assign the results to an array, the array would automatically evaluate as true. Boolean responses should have a bare return for false, but now I think I'm just getting picky. It still appears to be a very useful module.

        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      Thanks for the info on CGI::Simple! As someone who never uses the HTML side of CGI, this is perfect for a lot of projects I'm working on.
      Okay, that's offtopic enough =P
Re: lighter alternative to
by fglock (Vicar) on Aug 29, 2002 at 18:44 UTC
      Not exactly an answer to my question, but an interesting thought nonetheless. Thanks for the suggestion.
Re: lighter alternative to
by tstock (Curate) on Aug 29, 2002 at 18:57 UTC
    If it's such a small script, all you need is the functionality described, and performance is an issue, it would probably help not asking the OS to open another file. I am all for modularity, but it seems in your case (NTFS, NT, IIS, CGI, Perl) a little copy-paste modularity might help.

    PS: reader, whenever you feel someone you work with made a technical decision so bad to the point of being comical, please think back to this post. You are not alone...
Re: lighter alternative to
by dws (Chancellor) on Aug 29, 2002 at 20:20 UTC
    I'm helping out with a project that is using Perl from server-side includes on an NT box running IIS.

    Damn. You're probably really close to being able to invert the structure, and turn the HTML into a template. But that won't help your performance issue unless you can run mod_perl.

    Is this something you could use PerlScript for? You'd be getting some Cookie- and form-handling for free, and might be able to avoid (or a lighter alternative) entirely.

    The Perl-Win32-ASP FAQ has details.

      There are a few thousand .htm files using this SSI approach, and changing them all to .asp would be a big deal here. They're URLs that have existed for a long time and shouldn't be changed if possible.

      How I long for the flexibility of Apache right now...

Re: lighter alternative to
by gav^ (Curate) on Aug 29, 2002 at 20:35 UTC
    I've had good luck with ActiveState's Perl for ISAPI which comes with ActivePerl. This tends to speed things up a whole lot.

    We did try out PerlEx on a recent project that had to run on IIS and it was amazingly quick. Definatly worth the money.

    Hope this helps...


Re: lighter alternative to
by diakonos (Hermit) on Aug 29, 2002 at 20:03 UTC
    CGI Lite will probably be the closest replacement (with less headache) to but definately not as robust. If there was anyway possible to move to Apache webserver then by all means perl_mod would probably do the trick.

    My two cents are wheat pennies.

    Good Day!

      Naturally if I had that kind of control, we would be using Apache/mod_perl. However, I don't, so I have to find a solution that fits in the existing system. Thanks for the ++ on CGI_Lite.
      Geez! I menat to say mod_perl!!! I have to quit thinking that preview is for layout only. Sorry.
Re: lighter alternative to
by Anonymous Monk on Aug 30, 2002 at 05:03 UTC
    Take a look to CGI::Minimal
Re: lighter alternative to
by Vennis (Pilgrim) on Aug 30, 2002 at 09:09 UTC
    I personnally wouldn't use the next code and strongly advice to create a better running server...

    But, FYI, you can parse the parameters manually. Depending on the complexity, you could use this.

    If you use this 'wannahave a Big Ball of Mud solution' (i love that name) make sure you check the parameters for security problems.

    my $input; if ($ENV{REQUEST_METHOD} eq 'GET'){ $input = $ENV{QUERY_STRING}; } else { read(STDIN,$input,$ENV{CONTENT_LENGTH}); } foreach( split(/&/,$input)){ $_ =~ tr/+/ /; my ($name,$value) = split(/=/,$_,2); $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C",hex($1))/eg; if($param{$name}) { $param{$name}.= ",$value"; } else { $param{$name} = $value; } print "Found $name = $value\n"; }
      There's really no need to resort to that. Using a properly coded module does not add significant overhead. Replacing CGI with CGI_Lite turned out to improve overall performance of the script by 60%.