Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how?

by Anonymous Monk
on Aug 02, 2012 at 19:35 UTC ( #985096=note: print w/ replies, xml ) Need Help??


in reply to Re: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how?
in thread can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how?

Thanks flexvault... I had a similar idea while pondering all this.

Our application has a lot of file uploads, so many requests need to read several MB from STDIN -- which would complicate internal handoff. I was thinking I could have a script like /fast.pl which takes all GET requests and proxies them to a listener, as you describe, and then another script /upload.pl which accepts HTTP file uploads as traditional CGI.

Anyway, it is reassuring to know that somebody has actually done this and had it work well. We don't have mod_perl but perhaps I could just take the hit of running the 200-line stub as normal CGI, or I could write a persistent C# stub.


Comment on Re^2: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how?
Re^3: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how?
by flexvault (Parson) on Aug 03, 2012 at 09:36 UTC

    abcperl5,

    I wouldn't worry about not having mod-perl, with a script as small as 100-300 lines your talking milliseconds difference. Your testing will be a lot easier without mod-perl, since you can call the script from the command line. We didn't use mod-perl until we put the product into production.

    In your environment, with a lot of uploads, you wouldn't notice the compile step for Perl on the cgi script. The speed advantage is the persistent application that sits waiting to quickly respond to the cgi requests. From 'login' to 'logout' and all work in between, nothing has to be loaded after startup!

    We pre-forked the children so that they were waiting for work. The first time we tested, it looked like they never got called since our monitoring screen never changed from 'waiting' to 'working'. Checking the logs, it was working, but the time it took in the persistent application was faster than the refresh rate of the monitor.

    Good Luck!

    "Well done is better than well said." - Benjamin Franklin

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://985096]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (10)
As of 2014-10-21 03:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (95 votes), past polls