Nope... nevermind. You said it happened w/ 2.4.6 so that's
moot. 

On Nov 19, 2013, at 2:43 PM, Jim Jagielski <j...@jagunet.com> wrote:

> 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 <j...@jagunet.com> wrote:
> 
>> That's just weird...
>> 
>> On Nov 19, 2013, at 11:33 AM, Daniel Ruggeri <drugg...@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
>>>> 
>>> 
>> 
> 

Reply via email to