Would it make any difference on the speed / efficiency of my scripts if it was to be run using PerlEX or Perl for ISAPI?

Funny you should mention this, I was going to post a question on the same subject.

I have an aging Windows server that hosts an Oracle database, and I have written a large number of ad-hoc reports using Perl and boring old CGI with the HTML embedded inside (so shoot me).

All that is driven by perl.exe instances loading the CGI program, connecting to the database, and cranking out the results. All things considered, it's quite zippy, although it's an in-house app that gets a couple of thousand hits a day at best.

We're installing a new accounting system at work, with an MS SQl Server backend. We figured it would be pretty easy to steal the code from the other system and reuse it on this one, because that would mean we could supply web reports instead of having to deploy too many app front ends (with the attendant license fees).

It was easy enough to reuse the code. I installed the latest AS Perl, and I just had to fiddle with the DBI DSNs and it more or less worked. So I took the time to examine PerlIS and PerlEx to see about doing things the Right Way. I simply followed the installation procedure in the Activestate documentation. It's pretty straightforward. I then spent a few hours playing around with IIS settings, but I was not get anything resembling perl.exe performance.

It stank. When printing out a table, I could literally see each <td> element being rendered. Each table row was taking about 250 milliseconds to be printed out. Some sort of buffering impedance mismatch was occurring? I don't know. After a while I gave up, and in any event I couldn't figure out how to get it to apply taint checks anyway. So I went back to the perl.exe approach. The performance is very acceptable. And it's in-house only, so it's not as if it will ever be slashdotted.

I didn't have time to investigate more closely. The thing works for now, but I would like to get back to problem and try to get to the bottom of it. If anyone has had similar experience I'd be most insterested.

On the other hand, getting back to your question... all of our heavy web applications are running on mod_perl on FreeBSD. IIS has come a long way over the years, but it still has issues. Not more than a couple of months ago we were bitten by an exploit that could have caused us grief, but fortunately firewalls saved the day.

I have yet to experience an exploit with Apache. If you're planning on serving the general public, that is a much more important issue. Ditch ISS, ditch Windows. Install Linux or BSD, Postgresql or Mysql, and Apache, and learn to use them.

As has been alluded to by others, the problem with CGI on Windows has always been the process startup overhead, this is why the in-process techniques (such as ASP or ISAPI) have generally been preferred on that platform. PerlEX is not going to win you much in this environment, it might run faster and it might save you a bit of time in the compilation phase, but you are still creating a new windows process to handle the CGI.

The Activeperl installation will already have installed and configured the ISAPI Perl extension for you (unless you unchecked the default in the installer), so in principle you could just rename your CGI programs to have the .plx suffix and you could be away. That said however you will almost certainly need to take care with your code so that it works properly in the persistent environment (in much the same way as you would have to with a program running within mod_perl.) E.g. reduce the scope of all variables as much as possible, properly close all filehandles and avoid explicitly exiting the program among others.

I should probably mention Perlscript for ASP as well - ASP was really intended to replace ISAPI and is probably more efficient (though I have no data to back this up), the drawback is that you will have to rewrite most of your application to become Active Server Pages and quite honestly as, IMO, with all such embedded scripting environments (PHP, JSP and the handful of Perl equivalents) it can get messy really quickly if you don't apply strong software design principles from the outset.

/J\

Actually PerlEx does not work the way you describe. It is more like mod_perl or FastCGI. It's a moot point though, because the produce is no longer supported.

This FAQ links to another FAQ that explains how you go about configuring the ISAPI extension.

I haven't used the ISAPI Perl extension but you may wish to consider the following.

1. By default you will be sharing a process with other applications on the same server. You can isolate your application to avoid this. Remember to check file and registry permissions assigned to IWAM_<servername> in addition to the IUSR_<servername>.
2. Your Perl app is now running in a multi-threaded environment. Any modules (particularly if they load DLLs) that you use need to be thread safe.