Scalability with Perl CGI applications is a known issue. The problem is that the Perl interpreter loads every time as a new process in protected memory. Alternatives to increase scalability are FastCGI, mod_perl (for Apache) or Perl ISAPI on WinNT. This is taken from the ActivePerl online docs:
-------------------------------------------------------------
The main advantage of PerlIS over perl.exe is that PerlIS runs as a DLL in the web server's process space. Because Win32 platforms set up a protected memory space for each process that is started, there's a lot of overhead in starting a new process or program. Passing scripts to an interpreter, such as perl.exe, requires starting a new process for every script, which gets expensive in terms of system resources.
DLLs, on the other hand, don't need their own process space; they use the space of the process that calls them. They don't require nearly as much overhead to start, and once loaded they stay loaded until the calling process ends. PerlIS therefore runs Perl scripts with a quicker turn-around time than perl.exe.
Extra care should be taken when you write PerlIS applications. It is difficult to crash the web server using CGI, but because the PerlIS DLL runs in the process space of the server, your web server is more susceptible to crashes and hangs caused by programming errors.
-------------------------------------------------------------
Hope this helps. There are lots of good books out there on this topic.
Kind regards,
Trevor Joerges
http://tjoerges.homeip.net
-----Original Message-----
From: MILLER David R. [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 27, 2001 4:31 PM
To: Perl-Win32-Web (E-mail)
Subject: Web app advice
I've created a Perl-driven web app that delivers a high-stakes examination
to remote computer labs. We recently ran a session and experienced some
problems that I am seeking advice on.
Perl v5.6.1, ... Binary build 629
DBI::DBD.pm,v 10.8 2000/06/11 00:06:02
DBD::ODBC.pm,v 1.12 1998/08/14 19:29:50
Windows 2000
IIS 5
SQL Server 7.0
Although things went well in testing, in practice our server memory usage
went nuts past a threshold of perhaps 100 simultaneous users. We're not sure
why, but the clues seem to point to the DBI. I realize that specific advice
is impossible without seeing code, but at the moment I'm asking two general
questions:
1. Are there scalability issues with DBI/DBD/ODBC that I should be aware of?
(The last time we ran the exam I was still using Win32::ODBC and didn't see
this particular problem, although the current code is definitely more
database-intensive.)
2. The big lesson is that we have to stress-test our app. I need to create a
host of virtual candidates taking the exam so I can try out different
components and different scenarios. Does anyone have recommendations for a
suitable tool for doing this, Perl-based or otherwise? I can't say that
price is not a factor, but the costs and stress associated with a server
meltdown are pretty considerable.
TIA
---------------FROM-------------------
David R. Miller
Manager, Computer-Based Testing
Medical Council of Canada
[EMAIL PROTECTED]
(613) 521-6012
(613) 521-9722 (fax)
-----------------------------------------
_______________________________________________
Perl-Win32-Web mailing list
[EMAIL PROTECTED]
http://listserv.ActiveState.com/mailman/listinfo/perl-win32-web
