httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: UDS Patch
Date Tue, 19 Nov 2013 19:43:40 GMT
OK... the DNS lookup code seems to have changed between 2.4.6 and 2.4.7:

	https://svn.apache.org/viewvc?view=revision&revision=1511313

So I'm wondering if there's something there.

On Nov 19, 2013, at 12:08 PM, Jim Jagielski <jim@jaguNET.com> wrote:

> That's just weird...
> 
> On Nov 19, 2013, at 11:33 AM, Daniel Ruggeri <DRuggeri@primary.net> wrote:
> 
>> Well, I don't have good news to report... doesn't seem to be a
>> significant change in behavior...
>> nginx:
>> Requests/sec:   5082.43
>> Requests/sec:   5111.94
>> Requests/sec:   5063.27
>> 
>> 2.4.6 - First UDS patch:
>> Requests/sec:   4733.09
>> Requests/sec:   4529.49
>> Requests/sec:   4573.27
>> 
>> 2.4.6 - r1511313 + new UDS patch + r1543174:
>> Requests/sec:   3774.41
>> Requests/sec:   3878.02
>> Requests/sec:   3852.34
>> 
>> Will try to look into this next week...
>> 
>> --
>> Daniel Ruggeri
>> 
>> On 11/18/2013 6:37 PM, Daniel Ruggeri wrote:
>>> On 11/18/2013 3:38 PM, Jim Jagielski wrote:
>>>> Can you retry with this applied:
>>>> 
>>>> 	https://svn.apache.org/viewvc?view=revision&revision=1543174
>>> Definitely. I'll report back tomorrow so long as the universe wills
>>> it... but one last note....
>>> 
>>> I failed to mention in my original notes that there were two hunks that
>>> didn't apply cleanly to 2.4.6 - these appear to be from this change:
>>> https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c?r1=1511313&r2=1511312&pathrev=1511313
>>> ... which is in the neighborhood of what you adjusted in r1543174... but
>>> doesn't appear to conflict directly.
>>> 
>>> I'm thinking I should also apply r1511313 to 2.4.6 as a prereq to
>>> r1543174 in order to remove ambiguity... I'm frankly not sure if the
>>> machine was performing DNS lookups during the test or not (and I have
>>> only given this a cursory review), but that would *definitely* account
>>> for a measurable slowdown.
>>> 
>>> The context of what was rejected:
>>>> --- modules/proxy/proxy_util.c
>>>> +++ modules/proxy/proxy_util.c
>>>> @@ -2228,7 +2324,8 @@
>>>>            conn->port = uri->port;
>>>>        }
>>>>        socket_cleanup(conn);
>>>> -        if (!worker->s->is_address_reusable || worker->s->disablereuse)
{
>>>> +        if (!(*worker->s->uds_path) &&
>>>> +            (!worker->s->is_address_reusable ||
>>>> worker->s->disablereuse)) {
>>>>            /*
>>>>             * Only do a lookup if we should not reuse the backend
>>>> address.
>>>>             * Otherwise we will look it up once for the worker.
>>>> @@ -2239,7 +2336,7 @@
>>>>                                        conn->pool);
>>>>        }
>>>>    }
>>>> -    if (worker->s->is_address_reusable && !worker->s->disablereuse)
{
>>>> +    if (!(*worker->s->uds_path) && worker->s->is_address_reusable
&&
>>>> !worker->s->disablereuse) {
>>>>        /*
>>>>         * Looking up the backend address for the worker only makes
>>>> sense if
>>>>         * we can reuse the address.
>>> I'll have to see what the delta with both patches applied turns out to be...
>>> 
>>> --
>>> Daniel Ruggeri
>>> 
>> 
> 


Mime
View raw message