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
>>>
>>
>
