Greetings. [...] > > This documentation patch addresses the single thread snafu on Win32. > > Comments, corrections and additions (even subtractions) > >welcome. (Also on the hot topic of the day: where in the doc does this fit?) > > Nice, but please repost it inlined. Otherwise people won't be able to > comment on your words. [...]
mmmmhhh I see - attachment stripping. So here it comes - brace. -----SNIP---SNIP---SNIP---(sigh, the good ole days)---- =head1 OS caveats: multithreading on Windows NT =head2 The problem mod_Perl's multithreading capability is severely limited on Win32 platforms (WinNT and Win2K). It is in fact limited to the point of non-existence: mod_perl on Win32 is single threaded. A single instance of the interpreter is created, and it is protected with a server-wide lock, that prevents more than one thread to be using the interpreter at any one time. It is actually a little worse than that, as not only does the interpreter lock prevents parallel processing of perl requests, it also prevents B<any> request to proceed (yes, this means that static content requests will also be blocked). This rather unfortunate situation is supposed to change when Apache 2.0 and mod_perl 2.0 will be officially released: in the 2 series, with full multithreading support, apache will be managing an interpreter pool whose dimensions (among other parameter) will be tunable, as documented in http://perl.apache.org/~dougm/modperl_2.0.html The 2.0 release is still some time away unfortunately, which means that users of 1.3.x are stuck in single threaded world. =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. 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 queued 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. As a real life example, think a manufacturing application where, most of the time, users are navigating a Bill Of Material - a hierarchical structure. The requests generated by this usage pattern have a rather short service time, when moving from a component (node) of the BOM to one of its children or siblings. Now and then, however, a new Bill Of Material is requested, an operation that may require up to 25 seconds to complete. During this time lapse, all other requests are queued, nobody is able to use the system, and everybody complains about being "stuck". By contrast, the very same application, B<running against a fixed BOM>, falls in the first category above, and may be perfectly happy in a single CPU mod_perl environment. =head2 Workarounds If you need multithreading on Win32, either because your problem falls in the second category or because you can afford multiprocessor hardware, and assuming you cannot switch operating system, there is not much you can do - other than waiting for 2.0, that is. The only mod_perl solution to this problem appears to be a multi_server load balancing setup which uses mod_rewrite (or a URL partitioning scheme) to spread requests on several web servers, listening on different ports. 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 similar 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 you cannot do any of the above, then you will have to turn to some non mod_perl alternative. 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). This said, your mileage will doubtlessly vary. -----SNIP---SNIP---SNIP---(back to the future)----- Cheers, alf
