Scaling issue with Perl web application and IIS on Windows

Posted by on 2013-09-10 07:30

We have a webstore application running on Windows Server 2008 R2 64 bit and on Windows Server 2003 32bit. The 2003 server has 4 CPUs and 12GB of RAM and the 2008 server has 8CPUs and 24GB of RAM.

It consists of 20 or so Perl scripts. We have Perl 5.16.3 installed.

We are using the PDK to package these into exes.

We are finding that when the server becomes busy - 200 or more users - the CPU pretty much remains at 100%. The memory is not an issue and throwing more memory at the servers has not seemed to help. The exes start to take a long time to execute resulting in 5 or more minutes between page loads sometimes. With just a few users it runs perfectly fine. We haven't determined what the "magic" number is but it does appear to get exponentially worse not geometrically worse as more users are added.

We have looked into running these as native .pl scripts rather than the packaged exes but that did not seem to alleviate the congestion. Instead of many webstore.exe processes that took a long time, there were many perl.exe processes that took a long time.

I have just recently looked into PerlEx. I noticed that there is no version of this for 64bit. So I installed the 32bit version on a 2008 64bit server. I haven't got it working yet and may need to do some re-programming. The scripts work the first time that they are encountered but then the second time a "Script failed to send data." error is received and then I get 500 errors. Stop and start IIS and it works the first time again.

Could these issues be due to the 32bit version on a 64bit machine?

Is PerlEx something that is still supported/maintained?

Are there other recommended ways to run Perl scripts on a Windows Server running IIS as the web server or should I be looking at a different OS or different web server?

ActiveState Staff
Fri, 2014-01-10 13:53

Are you getting error logs from PerlEX? The logs will usually contain more detail than is available elsewhere.

If you are not getting any logs, that could be a configuration problem. The default ID used by IIS 7.x may not have permission to write to the default logging path. That could cause PerlEX to block when it tries to write an event. You may be able to make progress by adjusting the Trace registry entry (to control verbosity) and/or set the LogPath registry entry to a directory usable by the default ID.