RE: Documentation patch for mod_perl//win32
Hi there, On Fri, 23 Nov 2001, Alessandro Forghieri wrote: > I sure can co-maintain such a document. The "co" part is a good idea for > several reasons - the most cogent being that I am not a native speaker Heck, you write English better than many Englishmen I know... 73, Ged.
[Fwd: Re: Documentation patch for mod_perl//win32]
Alessandro Forghieri wrote: > Greetings. > > Stas> so if Alessandro or Randy volunteers (please say so), please > Stas> ask winXX > Stas> users to send you more winXX specific notes/scenarios and you (the > Stas> volunteer) will be the official maintainer of the doc and send me the > Stas> new doc and then the future patches. For 2.0 you will simply have a > Stas> commit access and be able to maintain these by yourself and go wild. > Stas> Does this sound good? > > Randy> It does ... I'd be happy to volunteer, or co-volunteer if > Randy> Alessandro or anybody else wants, to do that for Win32. > > I sure can co-maintain such a document. The "co" part is a good idea for > several reasons - the most cogent being that I am not a native speaker > (I'm italian) and that I spend most of my time working behind a firewall, so > I'm not ideally suited for CVS access. Great! > And on this note, whenever Stas feels the revision process for this patch is > over, I'll send the definitive version... Then please communicate the patches/doc to Randy. I don't know a thing about winXX, so it's up to you to decide when the initial revision process is done. And even than nothing is cast in stone, I just thought that it would be a good idea to run this through the list while we just start this new document. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Documentation patch for mod_perl//win32
Greetings. Stas> so if Alessandro or Randy volunteers (please say so), please Stas> ask winXX Stas> users to send you more winXX specific notes/scenarios and you (the Stas> volunteer) will be the official maintainer of the doc and send me the Stas> new doc and then the future patches. For 2.0 you will simply have a Stas> commit access and be able to maintain these by yourself and go wild. Stas> Does this sound good? Randy> It does ... I'd be happy to volunteer, or co-volunteer if Randy> Alessandro or anybody else wants, to do that for Win32. I sure can co-maintain such a document. The "co" part is a good idea for several reasons - the most cogent being that I am not a native speaker (I'm italian) and that I spend most of my time working behind a firewall, so I'm not ideally suited for CVS access. And on this note, whenever Stas feels the revision process for this patch is over, I'll send the definitive version... Cheers, alf
Re: Documentation patch for mod_perl//win32
On Fri, 23 Nov 2001, Stas Bekman wrote: > Don't modify the guide, just throw some random and structured winXX > notes into a new doc,and we just add it to the guide as a new chapter. > Then people start sending patches and polish it, like the rest of the > chapters. The new 2.0 docs generation will have each OS specific notes > in its own chapter. > > so if Alessandro or Randy volunteers (please say so), please ask winXX > users to send you more winXX specific notes/scenarios and you (the > volunteer) will be the official maintainer of the doc and send me the > new doc and then the future patches. For 2.0 you will simply have a > commit access and be able to maintain these by yourself and go wild. > Does this sound good? It does ... I'd be happy to volunteer, or co-volunteer if Alessandro or anybody else wants, to do that for Win32. As well as these notes on limitations of the current mod_perl on Win32, there's also some basic installation/use things that have come up in the past that could also go in. best regards, randy
Re: Documentation patch for mod_perl//win32
Randy Kobes wrote: > On Wed, 21 Nov 2001, Alessandro Forghieri wrote: > > >>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. >> > > I wasn't aware of that ... perhaps the section of the guide you > refer to could be revised? Anyway, in that context, I think > having this section in isn't overkill, and would be good to leave > in. The revisions look good - balanced, yet detailed enough that > people reading it shouldn't get surprised by this behaviour. Don't modify the guide, just throw some random and structured winXX notes into a new doc,and we just add it to the guide as a new chapter. Then people start sending patches and polish it, like the rest of the chapters. The new 2.0 docs generation will have each OS specific notes in its own chapter. so if Alessandro or Randy volunteers (please say so), please ask winXX users to send you more winXX specific notes/scenarios and you (the volunteer) will be the official maintainer of the doc and send me the new doc and then the future patches. For 2.0 you will simply have a commit access and be able to maintain these by yourself and go wild. Does this sound good? On this note any volunteers to start working on OS specific notes for other OSs? (BSD/Solaris/AIX/HP-UX/Mac). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Documentation patch for mod_perl//win32
On Wed, 21 Nov 2001, Alessandro Forghieri wrote: > 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. I wasn't aware of that ... perhaps the section of the guide you refer to could be revised? Anyway, in that context, I think having this section in isn't overkill, and would be good to leave in. The revisions look good - balanced, yet detailed enough that people reading it shouldn't get surprised by this behaviour. best regards, randy
Re: Documentation patch for mod_perl//win32
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 snipsnip =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 alternati
Re: Documentation patch for mod_perl//win32
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. > [...] > > hhh 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 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 > Ma
Re: Documentation patch for mod_perl//win32
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. [...] hhh 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 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, 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 have quite a few problems related to assumptions that the application made about its environment, but that is not mod_perl or CGI fault).
