You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Issac Goldstand <ma...@beamartyr.net> on 2006/11/20 13:59:37 UTC
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
might shed some deeper insight into why things were/are done the way
they are, and what, if anything, would be needed to be done to make
things better.
I don't think that the problem is mod_perl, as much as the winnt MPM in
Apache2. The bottom line is that if anything goes wrong, you need the
singleton child process to recycle itself, and very often in the case of
mod_perl that can take a long time. But the essential problem still
exists with PHP, mod_python, even theoretically in a minimal vanilla
httpd install.
Issac
Foo JH wrote:
> This is a disappointing piece of news. Perl itself is very useful on
> the Windows environment. If modperl cannot be reliably deployed on
> Windows, how can we expect the Windows developers (which form the
> majority of developers) to consider adopting perl/ modperl for the
> enterprise?
>
> I hope we can find people who can testify otherwise...
>
> Issac Goldstand wrote:
>> YES! While it's acceptable for light and smallish applications, I've
>> never found it to be really usable once you're serving concurrent
>> connections.
>>
>> Issac
>>
>> Foo JH wrote:
>>> Hello guys,
>>>
>>> Just want to get some feedback from people here who use MP2 on
>>> Windows for their production enviromment. For myself I have done MP2
>>> on both FreeBSD and Windows platforms, and it seems to me that the
>>> FreeBSD combo is more reliable. The Windows version on occasion (but
>>> sure to happen) will throw out an error, and Apache will restart
>>> automatically. Does anyone share the same experience?
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Jorge Schrauwen <jo...@gmail.com>.
is this still compatible with the current trunk?
If so maybe it can be reactivated for trunk and 2.2?
>From what i gather from the info it seems interesting enough.
On 11/20/06, Mladen Turk <mt...@apache.org> wrote:
>
> Issac Goldstand wrote:
> >
> > I don't think that the problem is mod_perl, as much as the winnt MPM in
> > Apache2. The bottom line is that if anything goes wrong, you need the
> > singleton child process to recycle itself, and very often in the case of
> > mod_perl that can take a long time.
>
> There is experimental mpm_winxp that I did 2 years ago,
> but there was no real interest, so I didn't develop that
> further.
>
> http://people.apache.org/~mturk/
>
> Regards,
> Mladen
>
--
~Jorge
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Mladen Turk <mt...@apache.org>.
Issac Goldstand wrote:
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time.
There is experimental mpm_winxp that I did 2 years ago,
but there was no real interest, so I didn't develop that
further.
http://people.apache.org/~mturk/
Regards,
Mladen
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Philip M. Gollucci wrote:
> William A. Rowe, Jr. wrote:
>> Keep in mind, using the official build of httpd you have .pdb debug
>> files that can be downloaded that exactly match the .exe/.dll's/.so's
>> that we ship. That means you can -debug- these segfaults.
> Am I able to make these from UNIX ?
> Where can I read about this?
>
> Randy/Steve ?
I do -not- know what sort of debugging symbol tables are emitted from mingw
or cyg toolchains, but VC compile flag /Zi shoves out the symbols into a
compiler database (/Fd directs the output to a particular database name)
and the link flags /debug /opt:ref /incremental:no creates an .exe and
run time symbol database by the same name as the linked file (httpsd.exe
gains httpsd.pdb).
Here's where things get confusing and why devs disable or throw these .pdb
files away. 1 - compiler .pdb's aren't runtime symbol databases (different
formats, even - although both are named .pdb). You would only hang onto
a compiler .pdb that corresponds to a distributed link .lib binary. And
2 - the /Zi flag doesn't inhibit or change the optimization, and 3 - the
link flags /debug /opt:ref /incremental:no only differ from a /release
build by a couple of PE flags that identify the emitted .pdb. Finally,
4 - you must keep the exact .pdb's that correspond to the binaries. You
can't regenerate them reliably, and especially cannot generate them after
the fact with a slightly different version of the compiler.
Think of .exe + .pdb as an unstripped unix pe binary, the symbols in this
case -are- stripped, over to the .pdb. Users don't need the .pdb, but the
original binaries and .pdb file(s) must be present to open a user.dmp crash
file in a debugger, or for Dr Watson to produce truly intelligible output.
If you don't have a .pdb, and the compiler flag /Oy- is given, you can still
unwind the backtrace (with very limited clues). But /O2 (without /Oy-) will
optimize the calling frames - so without a .pdb such backtraces are illegible.
Hope this offers a few clues; I've started to toggle /Oy- always since it
makes a Dr Watson backtrace offer a few clues about a crash without having
to grab the user.dmp file. More hints are here;
http://httpd.apache.org/dev/debugging.html#backtrace-win
See
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Philip M. Gollucci wrote:
> William A. Rowe, Jr. wrote:
>> Keep in mind, using the official build of httpd you have .pdb debug
>> files that can be downloaded that exactly match the .exe/.dll's/.so's
>> that we ship. That means you can -debug- these segfaults.
> Am I able to make these from UNIX ?
> Where can I read about this?
>
> Randy/Steve ?
I do -not- know what sort of debugging symbol tables are emitted from mingw
or cyg toolchains, but VC compile flag /Zi shoves out the symbols into a
compiler database (/Fd directs the output to a particular database name)
and the link flags /debug /opt:ref /incremental:no creates an .exe and
run time symbol database by the same name as the linked file (httpsd.exe
gains httpsd.pdb).
Here's where things get confusing and why devs disable or throw these .pdb
files away. 1 - compiler .pdb's aren't runtime symbol databases (different
formats, even - although both are named .pdb). You would only hang onto
a compiler .pdb that corresponds to a distributed link .lib binary. And
2 - the /Zi flag doesn't inhibit or change the optimization, and 3 - the
link flags /debug /opt:ref /incremental:no only differ from a /release
build by a couple of PE flags that identify the emitted .pdb. Finally,
4 - you must keep the exact .pdb's that correspond to the binaries. You
can't regenerate them reliably, and especially cannot generate them after
the fact with a slightly different version of the compiler.
Think of .exe + .pdb as an unstripped unix pe binary, the symbols in this
case -are- stripped, over to the .pdb. Users don't need the .pdb, but the
original binaries and .pdb file(s) must be present to open a user.dmp crash
file in a debugger, or for Dr Watson to produce truly intelligible output.
If you don't have a .pdb, and the compiler flag /Oy- is given, you can still
unwind the backtrace (with very limited clues). But /O2 (without /Oy-) will
optimize the calling frames - so without a .pdb such backtraces are illegible.
Hope this offers a few clues; I've started to toggle /Oy- always since it
makes a Dr Watson backtrace offer a few clues about a crash without having
to grab the user.dmp file. More hints are here;
http://httpd.apache.org/dev/debugging.html#backtrace-win
See
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
William A. Rowe, Jr. wrote:
> Keep in mind, using the official build of httpd you have .pdb debug
> files that can be downloaded that exactly match the .exe/.dll's/.so's
> that we ship. That means you can -debug- these segfaults.
Am I able to make these from UNIX ?
Where can I read about this?
Randy/Steve ?
> I'd hope that modperl would do the same for their module (and the whole
> bundle if they ship httpd.) They are invaluable. Of course, you also
> need the .pdb file from perl58.dll itself, I'd expect.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
William A. Rowe, Jr. wrote:
> Keep in mind, using the official build of httpd you have .pdb debug
> files that can be downloaded that exactly match the .exe/.dll's/.so's
> that we ship. That means you can -debug- these segfaults.
Am I able to make these from UNIX ?
Where can I read about this?
Randy/Steve ?
> I'd hope that modperl would do the same for their module (and the whole
> bundle if they ship httpd.) They are invaluable. Of course, you also
> need the .pdb file from perl58.dll itself, I'd expect.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Foo JH wrote:
>
> By 'bad code' you're referring to code written by app developers? I
> suspected I fall into that category, but even when I throw in all the
> eval traps, the .dll errors still come to crash (and automatically
> restart) apache.
By bad code, I mean flaws in apr, httpd, modperl, perl applications...
anywhere that brings you a segfault.
Keep in mind, using the official build of httpd you have .pdb debug
files that can be downloaded that exactly match the .exe/.dll's/.so's
that we ship. That means you can -debug- these segfaults.
I'd hope that modperl would do the same for their module (and the whole
bundle if they ship httpd.) They are invaluable. Of course, you also
need the .pdb file from perl58.dll itself, I'd expect.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Foo JH wrote:
>
> By 'bad code' you're referring to code written by app developers? I
> suspected I fall into that category, but even when I throw in all the
> eval traps, the .dll errors still come to crash (and automatically
> restart) apache.
By bad code, I mean flaws in apr, httpd, modperl, perl applications...
anywhere that brings you a segfault.
Keep in mind, using the official build of httpd you have .pdb debug
files that can be downloaded that exactly match the .exe/.dll's/.so's
that we ship. That means you can -debug- these segfaults.
I'd hope that modperl would do the same for their module (and the whole
bundle if they ship httpd.) They are invaluable. Of course, you also
need the .pdb file from perl58.dll itself, I'd expect.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
> As Mladen hints, this was just 'the way it was done' since the Apache 1.3
> MPM was first created. I began to set up more of the structures for having
> parallel running httpd's and Mladen took this one step further with his
> winxp mpm, but the bottom line is that resource sharing just doesn't work
> the same way on windows as unix, and things like interlocking parallel
> writes by two processes to a log file, for example, still need additional
> work to behave without a huge performance hit.
>
> So you are strictly asking if winxp will ever become more tolerant of the
> processes crashing due to bad code?
By 'bad code' you're referring to code written by app developers? I
suspected I fall into that category, but even when I throw in all the
eval traps, the .dll errors still come to crash (and automatically
restart) apache.
I don't mind if performance is hit with the windows implementation of
modperl, since the usage is not exactly ebay load. But having
unpredictable cases of apache restarts - and a windows error message
popping out to state that fact - does give my administrators weak hearts.
I think the general game plan is that developers are able to rely on the
Windows platform for general deployments. The Linux/ FreeBSD alternative
is really when they need extra muscle for the job.
What with Java/ Ruby/ PHP/ .Net already working reliably on Windows,
it's difficult for modperl evangelists to convince their bosses that a
good language/ framework does not need to prove itself on the most
popular OS to date.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
> As Mladen hints, this was just 'the way it was done' since the Apache 1.3
> MPM was first created. I began to set up more of the structures for having
> parallel running httpd's and Mladen took this one step further with his
> winxp mpm, but the bottom line is that resource sharing just doesn't work
> the same way on windows as unix, and things like interlocking parallel
> writes by two processes to a log file, for example, still need additional
> work to behave without a huge performance hit.
>
> So you are strictly asking if winxp will ever become more tolerant of the
> processes crashing due to bad code?
By 'bad code' you're referring to code written by app developers? I
suspected I fall into that category, but even when I throw in all the
eval traps, the .dll errors still come to crash (and automatically
restart) apache.
I don't mind if performance is hit with the windows implementation of
modperl, since the usage is not exactly ebay load. But having
unpredictable cases of apache restarts - and a windows error message
popping out to state that fact - does give my administrators weak hearts.
I think the general game plan is that developers are able to rely on the
Windows platform for general deployments. The Linux/ FreeBSD alternative
is really when they need extra muscle for the job.
What with Java/ Ruby/ PHP/ .Net already working reliably on Windows,
it's difficult for modperl evangelists to convince their bosses that a
good language/ framework does not need to prove itself on the most
popular OS to date.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
> CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
> might shed some deeper insight into why things were/are done the way
> they are, and what, if anything, would be needed to be done to make
> things better.
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time. But the essential problem still
> exists with PHP, mod_python, even theoretically in a minimal vanilla
> httpd install.
As Mladen hints, this was just 'the way it was done' since the Apache 1.3
MPM was first created. I began to set up more of the structures for having
parallel running httpd's and Mladen took this one step further with his
winxp mpm, but the bottom line is that resource sharing just doesn't work
the same way on windows as unix, and things like interlocking parallel
writes by two processes to a log file, for example, still need additional
work to behave without a huge performance hit.
So you are strictly asking if winxp will ever become more tolerant of the
processes crashing due to bad code? Well, the answer is yes, either parallel
running child processes and/or hot standby have always been on the table; if
someone has time to design (as Mladen did with winxp mpm) and enough win folk
have time to review (something that hasn't happened with Mladen's design.)
That will never solve the problem that your dead process just took down dozens
of parallel requests in the process. And no - windows will never perform all
that well with 1 worker/process. If you want a very insecure MPM, it would
be possible to defer the process exit after a fault on one thread (suspending
that thread while the others run out) but this makes root exploits far easier
to design.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Mladen Turk <mt...@apache.org>.
Issac Goldstand wrote:
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time.
There is experimental mpm_winxp that I did 2 years ago,
but there was no real interest, so I didn't develop that
further.
http://people.apache.org/~mturk/
Regards,
Mladen
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
> CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
> might shed some deeper insight into why things were/are done the way
> they are, and what, if anything, would be needed to be done to make
> things better.
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time. But the essential problem still
> exists with PHP, mod_python, even theoretically in a minimal vanilla
> httpd install.
As Mladen hints, this was just 'the way it was done' since the Apache 1.3
MPM was first created. I began to set up more of the structures for having
parallel running httpd's and Mladen took this one step further with his
winxp mpm, but the bottom line is that resource sharing just doesn't work
the same way on windows as unix, and things like interlocking parallel
writes by two processes to a log file, for example, still need additional
work to behave without a huge performance hit.
So you are strictly asking if winxp will ever become more tolerant of the
processes crashing due to bad code? Well, the answer is yes, either parallel
running child processes and/or hot standby have always been on the table; if
someone has time to design (as Mladen did with winxp mpm) and enough win folk
have time to review (something that hasn't happened with Mladen's design.)
That will never solve the problem that your dead process just took down dozens
of parallel requests in the process. And no - windows will never perform all
that well with 1 worker/process. If you want a very insecure MPM, it would
be possible to defer the process exit after a fault on one thread (suspending
that thread while the others run out) but this makes root exploits far easier
to design.