You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2003/05/20 01:06:01 UTC
Tagged the tree
Hi,
I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
Sander
Re: Tagged the tree
Posted by Greg Ames <gr...@apache.org>.
Greg Ames wrote:
> Sander Striker wrote:
>
>> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
> It's running on daedalus on port 8092 now.
...and now it's live, as of Tuesday, 20-May-2003 14:21:27 PDT.
Greg
p.s. I hope this email gets thru. I've got ISP headaches today and haven't seen
earlier messages I posted.
Re: Tagged the tree
Posted by Greg Ames <gr...@apache.org>.
Sander Striker wrote:
> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
It's running on daedalus on port 8092 now. My usual tests look good. The live
httpd server is sort of busy at the moment, so I'll wait to bounce it. In the
mean time, I'll leave the test server running on port 8092 in case anyone else
wants to try anything.
Greg
RE: Tagged the tree
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> Sent: Wednesday, May 21, 2003 9:04 AM
> --On Tuesday, May 20, 2003 1:06 AM +0200 Sander Striker <st...@apache.org>
> wrote:
>
> > I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
>
> Looks good here with APACHE_2_0_BRANCH (passes httpd-test on Solaris).
>
> I backported into APACHE_2_0_BRANCH all outstanding patches that had 3 +1s and
> no negative or neutral votes in STATUS. No idea if you want to pick those up
> before .46 or not. My position is that I think we should as they all had 3
> +1s so we should be about as confident as we ever will on their quality - but
> it is ultimately your call as RM.
My position is that anything that is in now should go into 2.0.46. But, that
is mostly because the patches that went in since the tag don't make me nervous ;).
> The two changes I'd like to see in .46 that aren't in APACHE_2_0_BRANCH yet is
> the mod_dav MKACTIVITY fix
I agree on this one.
> and the apxs changes so that we work with out-of-tree APR and APR-util. I've
> added both of them to httpd-2.0's STATUS.
If two people other than me +1 it, I'll include it.
Sander
Re: Tagged the tree
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, May 20, 2003 1:06 AM +0200 Sander Striker <st...@apache.org>
wrote:
> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
Looks good here with APACHE_2_0_BRANCH (passes httpd-test on Solaris).
I backported into APACHE_2_0_BRANCH all outstanding patches that had 3 +1s and
no negative or neutral votes in STATUS. No idea if you want to pick those up
before .46 or not. My position is that I think we should as they all had 3
+1s so we should be about as confident as we ever will on their quality - but
it is ultimately your call as RM.
The two changes I'd like to see in .46 that aren't in APACHE_2_0_BRANCH yet is
the mod_dav MKACTIVITY fix and the apxs changes so that we work with
out-of-tree APR and APR-util. I've added both of them to httpd-2.0's STATUS.
-- justin
Re: Tagged the tree
Posted by André Malo <nd...@perlig.de>.
* Jeff Trawick wrote:
> Greg Stein wrote:
>> On Wed, May 21, 2003 at 09:19:25PM -0400, Jeff Trawick wrote:
>>
>>>The point is not WE CAN'T HAVE A RELEASE
>>
>>
>> Easy, Tex. I was just offering my thought.
>
> Some rich text formatting capabilities would be better in occasional
> situations (italics instead of uppercase?)...
Hehe, if you'd use *bold*, _underlined_ or /italics/ at least my client
would display it as desired :-)
nd
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://pub.perlig.de/ #
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Stein wrote:
> On Wed, May 21, 2003 at 09:19:25PM -0400, Jeff Trawick wrote:
>
>>The point is not WE CAN'T HAVE A RELEASE
>
>
> Easy, Tex. I was just offering my thought.
Some rich text formatting capabilities would be better in occasional
situations (italics instead of uppercase?)...
Re: Tagged the tree
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 21, 2003 at 09:19:25PM -0400, Jeff Trawick wrote:
> Greg Stein wrote:
> >On Wed, May 21, 2003 at 03:40:36PM -0400, Jeff Trawick wrote:
> >
> >>Jeff Trawick wrote:
> >>
> >>>Sander Striker wrote:
> >>>
> >>>
> >>>>I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
> >>
> >>time to disagree with myself... starting to see a performance
> >>regression w.r.t. 2.0.45 on AIX with simple static file serving...
> >>degradation is on the order of 2-3%
> >
> >
> >I wouldn't hold up a release for that...
>
> The point is not WE CAN'T HAVE A RELEASE
Easy, Tex. I was just offering my thought.
eesh,
-g
--
Greg Stein, http://www.lyra.org/
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Stein wrote:
> On Wed, May 21, 2003 at 03:40:36PM -0400, Jeff Trawick wrote:
>
>>Jeff Trawick wrote:
>>
>>>Sander Striker wrote:
>>>
>>>
>>>>I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
>>
>>time to disagree with myself... starting to see a performance
>>regression w.r.t. 2.0.45 on AIX with simple static file serving...
>>degradation is on the order of 2-3%
>
>
> I wouldn't hold up a release for that...
The point is not WE CAN'T HAVE A RELEASE
The point is
- something is potentially messed up
- is anybody else seeing this?
- I'm still investigating
- if the cause is found and it is not working as desired, it can be
fixed before the release
The degradation could be some extra checks that are desired, it could be
due to paging activity related to a storage leak, who knows...
Re: Tagged the tree
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 21, 2003 at 03:40:36PM -0400, Jeff Trawick wrote:
> Jeff Trawick wrote:
> >Sander Striker wrote:
> >
> >>I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
>
> time to disagree with myself... starting to see a performance
> regression w.r.t. 2.0.45 on AIX with simple static file serving...
> degradation is on the order of 2-3%
I wouldn't hold up a release for that...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> this is weird, and will very possibly turn out to be something stupid
> I'm doing, but it is so consistent
I give up trying to put my finger on it.
Switching between old libs and new libs, switching some of my thin set
of modules back and forth between 2.0.45 and 2.0.46-pre1, each has some
almost imperceptable change, some for the better and some not, but none
of the changes is big enough to be obvious.
heavy sigh
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> Jeff Trawick wrote:
>
>> Sander Striker wrote:
>>
>>> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
>
>
> time to disagree with myself... starting to see a performance
> regression w.r.t. 2.0.45 on AIX with simple static file serving...
> degradation is on the order of 2-3%
this is weird, and will very possibly turn out to be something stupid
I'm doing, but it is so consistent
I started playing on RH 9, and also on that box 2.0.46-pre1 is
consistently slower than 2.0.45 (though not as dramatically as on
AIX)... interestingly: plug new apr/aprutil into 2.0.45 and it gets a
little faster, plug old apr/aprutil into 2.0.46-pre1 and it gets a
little slower; so there is some good news out of this :)
2.0.45's ab has a storage leak seen over 100,000 requests... it ends up
with more storage than an Apache worker child process after a while...
presumably 2.0.46-pre1's ab does too
2.0.46-pre1 httpd doesn't seem to be leaking storage
looking at diffs between the trees...
the new get_server_name_for_url() has an extra strchr() if
APR_HAVE_IPV6, but we don't get there for a straight static page served
to ab
the disable nagle stuff seems to be right (disabled on the listening
socket, calls to apr are noops on connected sockets, just as with 2.0.45)
time to learn oprofile I guess
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> Sander Striker wrote:
>
>> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
time to disagree with myself... starting to see a performance
regression w.r.t. 2.0.45 on AIX with simple static file serving...
degradation is on the order of 2-3%
anybody else seeing this?
will try to find a cause later
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> Sander Striker wrote:
>
>> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
> general problems:
>
> 1) ab hits a timeout ("-t 20") infrequently with the mod_ext_filter+sed
> test (both 2.0.45 and 2.0.46-pre1 get this at about the same
> frequency); I didn't check if increasing the timeout would help,
> as 20 seconds seems quite generous... conceivably this could be an ab
> problem, but I haven't looked into it
not a release issue (broken since the beginning of time), but this isan
interesting APR issue... see the thread "challenges creating processes
from threaded environment?" on dev@apr
> 2) a few different mod_cgid failures seen... sporadic... both 2.0.45
> and 2.0.46-pre1 seem to hit these errors at about the same frequency; I
> tried debugging on Solaris, but running truss on the cgid daemon is
> sufficient to make it reliable :)
>
> here is the oddest flavor of cgid failure, that I saw only twice:
> [Wed May 21 12:59:39 2003] [error] [client 127.0.0.1] (9)Bad file
> descriptor: mod_mime_magic: read failed:
> /home/trawick/ph/2.0.46-pre1/built/cgi-bin/printenv
this mod_mime_magic failure was extremely rare... I wonder if it got
bit by the same problem as mod_ext_filter, as mod_mime_magic could have
been spawning an uncompress program from multiple threads
Re: Tagged the tree
Posted by Jeff Trawick <tr...@attglobal.net>.
Sander Striker wrote:
> I just tagged the tree with STRIKER_2_0_46_PRE1. Please test.
test bucket:
build similar to Apache binbuild, everything DSO, worker, cgid,
mod_deflate is built via apxs together with required zlib .c files
verify that all modules can be loaded
verify that apachectl still works after renaming lib directory and
editing bin/envvars as appropriate
run most apr regression tests
run most apr-util regression tests
make sure httpd on Solaris references libpthread
simple mod_deflate tests with ab
simple mod_ext_filter tests with ab (use sed for filter)
simple printenv CGI tests with ab
static file tests with ab
try to load some 3rd-party modules built with prior level of Apache
(only tested on a few platforms)
general problems:
1) ab hits a timeout ("-t 20") infrequently with the mod_ext_filter+sed
test (both 2.0.45 and 2.0.46-pre1 get this at about the same
frequency); I didn't check if increasing the timeout would help,
as 20 seconds seems quite generous... conceivably this could be an ab
problem, but I haven't looked into it
2) a few different mod_cgid failures seen... sporadic... both 2.0.45
and 2.0.46-pre1 seem to hit these errors at about the same frequency; I
tried debugging on Solaris, but running truss on the cgid daemon is
sufficient to make it reliable :)
here is the oddest flavor of cgid failure, that I saw only twice:
[Wed May 21 12:59:39 2003] [error] [client 127.0.0.1] (9)Bad file
descriptor: mod_mime_magic: read failed:
/home/trawick/ph/2.0.46-pre1/built/cgi-bin/printenv
platforms tested:
HP-UX 11.00 - encountered the occasional mod_ext_filter+sed error
Solaris 8 - encountered sporadic mod_cgid errors and the occasional
mod_ext_filter+sed error
RedHat Linux 6.2 on Intel - encountered the occasional
mod_ext_filter+sed error
AIX 5.1 - encountered sporadic mod_cgid errors and the occasional
mod_ext_filter+sed error
UnitedLinux 1.0 on ppc64 - encountered the occasional mod_ext_filter+sed
error
also encountered a unique flavor of mod_cgid error:
[Wed May 21 13:38:29 2003] [error] [client 127.0.0.1] (9)Bad file
descriptor: unable to connect to cgi daemon after multiple tries:
/home/trawick/ph/2.0.46-pre1/built/cgi-bin/printenv
from a look at the code, that is a should-not-occur, whether errno is
from the connect() or from the close() in the error path
--/--
so, not perfect but not worse than 2.0.45, and presumably many other
things are better
thus, +1 for release