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

<Disclaimer> Haven't done this on Windows!</Disclaimer>

But I have done this on *nix!

Years ago I would use 'mod-perl', but Perl and mod-perl are moving apart (IMHO). So on one of my recent gigs, I used a persistent Perl parent/forked process ( ~25,000 lines ).

The web server called a small cgi mod-perl script ( ~200 lines ) that sent the request to the persistent process using sockets, wait for the response, and then sent that response to the webserver. The performance was fantastic. With prototyping, eventually we got 8-10 requests per second per core. The input was 200-400 bytes, but the output could be 30K-200K bytes of HTML text.

Good Luck!

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

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

Replies are listed 'Best First'.
Re^2: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how? by BrowserUk (Patriarch) on Aug 03, 2012 at 09:49 UTC
The web server called a small cgi mod-perl script ( ~200 lines ) that sent the request to the persistent process using sockets, wait for the response, and then sent that response to the webserver. How does that differ from fastcgi? (That's a real question not an admonishment. I don't do webstuff :) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^3: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how? by flexvault (Monsignor) on Aug 03, 2012 at 10:21 UTC
Hello BrowserUk, How does that differ from fastcgi? Since you know that I support a lot of different nix type systems, I found it easier to define the HTTP, javascript, etc. differences as well as the different forks per core per server. Even different Linux distributions needed tinkering when using the 'same' web-server. I did try fastcgi and pperl(persistent perl) and a few more. In concept they do exactly what I did, but the 'devil is in the detail'. For example, I used pperl on a server that I could 'ssh' to and run persistent scripts, but if I connected the 1st time as 'aixterm' and then later as 'wyse60', all hell broke out. Now maybe an pperl expert would tell me "just ...", but I just couldn't find the information in the documentation. At that time in my Perl development, I didn't know about PM! Thank you "Well done is better than well said." - Benjamin Franklin*	[reply]
Re^3: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how? by Anonymous Monk on Aug 03, 2012 at 09:52 UTC
:)(I'm guessing) Its written in pure-perl, and (probably) ad-hoc without an accompanying RFC (like FastCGI/PSGI)	[reply]
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
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.	[reply]
Re^3: can Perl-CGI run persistently on Windows 2008 with IIS 7.5? how? by flexvault (Monsignor) 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	[reply]