Greetings. Randy> That's great that you thought this out and put it together; Randy> a few comments below appear below ...
Thanks for playing editor - and I am accepting all of your suggestions, with the possible exception of what follows. Randy> I got confused about which is the "first" and which is the Randy> "second" category ... However, is this much detail needed? The reason this section got in there is that a previous version of the guide included a highly opinionated quote against multithreading on single processor machines, which totally failed to take into account applications with long running requests (except for saying that such apps should not exist). Hence the counter-example, which I have now somewhat shortened. If there is still a consensus on it being overkill, I can drop it altogether. The revised version is below. Cheers, alf ----snip----snip---- =for RCS $Id: modperl_multithread_NT.pod,v 1.2 2001/11/21 10:09:30 forghier Exp forghier $ =head1 OS caveats: multithreading on Windows NT =head2 The problem On Win32, mod_perl is effectively single threaded. What this means is that a single instance of the interpreter is created, and this is then protected by a server-wide lock that prevents more than one thread from using the interpreter at any one time. The fact that this will prevent parallel processing of requests, including static requests, can have serious implications for production servers that often must handle concurrent or long-running requests. This situation will change with Apache/mod_perl 2.0, which is based on a multi-process/multi-thread approach using a native Win32 threads implementation. See http://perl.apache.org/~dougm/modperl_2.0.html for details. At the time of writing, Apache-2.0 is in a beta stage of development. mod_perl-2.0 is being actively developed, including the Win32 port; if you would like a preview and/or would like to contribute to the development process, see the documents on obtaining mod_perl-2.0 by cvs, which can be obtained from mod_perl's home page (http://perl.apache.org) =head2 Does it really matter? How serious is this? For some people and application classes it may be a non-problem, assuming the static material issue is handled differently. Low traffic and single user development sites will likely be unaffected (though the lattest are likely to experience some surprises when moving to an environment where requests are no longer serialized and concurrency kicks in). If your application is CPU bound, and all requests take roughly the same time to complete, then having more processing thread than processors (CPUs) will actually slow things down, because of the context switching overhead. Note that, even in this case, the current state of mod_perl will bar owners of multiprocessor Win32 machines from gaining a load balancing advantage from their superior hardware. On the other hand, applications dealing with a large service times spread - say ranging from fractions of a second to a minute and above - stand to lose a great deal of responsiveness from being single threaded. The reason is that short requests that happen to be queueued after long ones will be delayed for the entire duration of the "jobs" that precede them in the queue; with multitasking they would get a chance to complete much earlier. =head2 Workarounds If you need multithreading on Win32, either because your application has long running requests, or because you can afford multiprocessor hardware, and assuming you cannot switch operating system, you may want to consider a few workarounds and/or alternatives - which do not require waiting for 2.0. You may be able to make Win32 multithreading a non-issue by tuning or rearranging your application and your architecture (useful tips on both counts can be found elsewhere in this document). You may be able to significantly reduce your worst-case timing problems or you may find that you can move the webserver to a more mod_perl friendly operating system by using a multi tier scheme. If your application needs the full power of the Apache modules (often the case for people running outside Apache::Registry) you may want to consider a multi_server load balancing setup which uses mod_rewrite (or a similar URL partitioning scheme) to spread requests on several web servers, listening on different ports. The mod_proxy dual server setup,discussed in the "Strategy" section, is also a possibility, although people who have tried it have reported problems with Win32 mod_proxy. If you code to Apache::Registry (writing CGI compliant code) and can characterize the time demanded by a request from its URL, you can use a rewrite based load balancing with a single server, by sending short requests to mod_perl while routing longer ones to the pure CGI environment - on the basis that startup, compilation and init times will matter less in this case. If none of the above works for you, then you will have to turn to some non mod_perl alternatives: this, however, implies giving up on most of the flexibility of the Apache modules. For CGI compliant scripts, two possible (portable) alternatives which are supported in an Apache/perl environment are straight CGI and FastCGI. In theory a CGI application that runs under mod_perl should have very few or none problems to run under straight CGI (though its performance may be unacceptable). A FastCGI port should also be relatively painless. My personal test of this theory tends to corroborate it: starting from an Apache::Registry CGI script, I had no perl-related problems when moving it to a CGI environment and very few for FastCGI. (I B<did> have quite a few problems related to assumptions that the application made about its environment, but that is not mod_perl or CGI fault). The application I was working with, however, had been carefully modularized and had CGI compliance as a design secification, so expect your mileage to vary. If you do not mind replacing Apache with IIS/PWS (I do), you may want to experiment with ActiveState's value added PerlEx extension, which speeds up CGI scripts much in a way similar to what FastCGI does. PerlEx is transparently supported by CGI.pm, so users of this package should be more or less covered. (A IIS-FastCGI accelerator is, regrettably, no longer available.)
