On Tue, 20 Nov 2001, Alessandro Forghieri wrote: > 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.
That's great that you thought this out and put it together; a few comments below appear below ... > > -----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 above, and a couple places below, come off to me as being quite down on Win32 mod_perl, especially as an introduction. Although in general one shouldn't generalize, I think it's fair to say that many mod_perl Win32 users use it for exploration and/or development, and this intro might raise needless concern. What about the following: ******************************************************************** =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. **************************************************************** > The 2.0 release is still some time away unfortunately, which means > that users of 1.3.x are stuck in single threaded world. For those affected, it's probably a good idea to be a bit more specific; how about *************************************************************** 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. *************************************************************** > > =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. It's also not a problem for low traffic sites and for people using Win32 for single-user development ... > > 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. I got confused about which is the "first" and which is the "second" category ... However, is this much detail needed? It seems to me the upshot of the above is that if one has a long-running request to complete, all requests will be blocked until this request finishes, but this has already been stated in the introduction. In the spirit of the guide, for example, perhaps more space should be spent on possible solutions, as below ... > =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. But there being "not much you can do" contradicts the next paragraph ... > > 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. One could also try a dual server set-up using mod_proxy, as discussed in the guide, although people who've tried it have reported problems with Win32 mod_proxy. Another thing that should be mentioned is tuning things, as discussed in the performance section of the guide; perhaps a long-running process can be made acceptably short by these techniques. > > 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. One could also mention ActiveState's PerlEx ... However, these solutions are specific to Apache::Registry type of scripts, and of course mod_perl is more than that ... > > 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. I'm not sure of the generality of the above - this probably reflects more your obvious care in coding ... Anyway, the above comments are not meant negatively - it's always easier to edit something. Such a document as this is needed; the above is just trying to give a more positive slant, if possible. best regards, randy kobes
