You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2013/11/18 22:38:25 UTC
UDS Patch
Can you retry with this applied:
https://svn.apache.org/viewvc?view=revision&revision=1543174
On Nov 18, 2013, at 2:39 PM, Daniel Ruggeri <DR...@primary.net> wrote:
> And... this is a bit discouraging, but as a comparison to the older UDS
> patch....
> 2.4.6 + original UDS patch:
> Requests/sec: 5347.17
> Requests/sec: 5102.16
> Requests/sec: 5074.15
>
> This is a sizable difference... Note that the current 2.4 backport
> proposal was applied to 2.4.6 since that is what I tested the original
> patch with (to keep everything apples to apples).
>
> I'll jump in to take a look at this when time is available (next week?)
> but would like to fish for any immediate thoughts in the mean time.
>
> --
> Daniel Ruggeri
>
> On 11/18/2013 1:11 PM, Daniel Ruggeri wrote:
>> Oops - I copypasta'd the per-thread stats. Total stats for the test follow:
>> httpd:
>> Requests/sec: 4633.17
>> Requests/sec: 4664.49
>> Requests/sec: 4657.63
>>
>> nginx:
>> Requests/sec: 5701.16
>> Requests/sec: 5798.08
>> Requests/sec: 5584.60
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 5, 2013, at 2:03 PM, Daniel Ruggeri <DR...@primary.net> wrote:
>
> httpd-2.4.6 - w new patches
> Requests/sec: 35745.11
> Requests/sec: 36763.18
> Requests/sec: 36568.09
>
> httpd2.4.6 - original UDS patch
> Requests/sec: 24413.15
> Requests/sec: 24015.11
> Requests/sec: 24346.76
>
>
w00t!!!!
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
Thanks for getting back about that. Two days ago I retried and was able
to tease out what appeared to be environmental variance in my numbers .
After modifying the configuration to eliminate cruft as well as
replacing the app with nothing more than a simple 'hello world' type of
responder (over 32 running processes), I was able to get a much more
reasonable set of numbers. The results, tested over a few hours were
also quite stable:
httpd-2.4.6 - w new patches
Requests/sec: 35745.11
Requests/sec: 36763.18
Requests/sec: 36568.09
httpd2.4.6 - original UDS patch
Requests/sec: 24413.15
Requests/sec: 24015.11
Requests/sec: 24346.76
The nginx server is in use by another application right now so I was
unable to test it for an apples to apples comparison.... but this
confirms exactly as you expected, the newer patch set is faster than the
original UDS patch. I agree that decoding as well as the string
comparison in the critical path is the most likely culprit there... but
that's old hat anyway.
So, in short, my past test cases were invalid because they included
other bottlenecks. Sorry for unnecessary noise!
--
Daniel Ruggeri
On 12/5/2013 6:54 AM, Jim Jagielski wrote:
> My test setup looks pretty much the same as yours: a simple
> node.js server listening on the UDS path, but mine serves
> just static content.
>
> On Dec 2, 2013, at 7:04 PM, Daniel Ruggeri <DR...@primary.net> wrote:
>
>> I had the same inclination as Cristophe but haven't been able to
>> substantiate anything due to lack of time.... last week wasn't as kind
>> to my free time as I had hoped. This would be very easy to tweak/test.
>> Within the next day or two I should be able to get back in to perform
>> some rebuilds and do more thorough testing and tampering as I squeeze
>> time in between various work-related crises. Most of my testing is
>> automated-ish, so turnaround from patch to test results is fairly quick.
>>
>> Jim, what does your test setup look like to measure performance delta?
>> My setup is fairly simple with httpd on the frontend targeting a small
>> Node.js backend application... I don't suspect the application is
>> skewing the results because of how consistent the results have been, but
>> I may just remove that from the equation to be absolutely sure.
>>
>> --
>> Daniel Ruggeri
>>
>> On 12/2/2013 8:14 AM, Jim Jagielski wrote:
>>> But from what I see, all of those are during non critical paths.
>>> It's like when workers are being defined, initialized, etc and
>>> that's only done during config or when added via balancer-manager.
>>>
>>> On Dec 2, 2013, at 8:09 AM, Marion et Christophe JAILLET <ch...@wanadoo.fr> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> one of my thought was the change from
>>>>
>>>> worker->s->name
>>>>
>>>> to
>>>>
>>>> ap_proxy_worker_name(r->pool, worker)
>>>>
>>>> in logging function.
>>>>
>>>> ap_proxy_worker_name allocates memory in the pool and performs some operations on strings (apr_pstrcat).
>>>>
>>>>
>>>> These operations are performed in all cases, even if DEBUG messages are not logged.
>>>>
>>>>
>>>> I don't think this should have a real effect on performance. (If I remember well when I looked at it, there is no ap_log_error calls in sensitive code)
>>>>
>>>> Just to be sure, you could try to simplify ap_proxy_worker_name in Daniel's build to remove the apr_pstrcat and check performance with his build.
>>>>
>>>>
>>>> Should you and Daniel have different logging levels, it could explain why you don't measure the same discrepancy.
>>>>
>>>>
>>>>
>>>> Just my 2 cents.
>>>>
>>>> If I have time, I'll give another look tonight.
>>>>
>>>>
>>>> CJ
>>>>
>>>>
>>>>
>>>>
>>>>> Message du 02/12/13 13:46
>>>>> De : "Jim Jagielski"
>>>>> A : dev@httpd.apache.org
>>>>> Copie à :
>>>>> Objet : Re: UDS Patch
>>>>>
>>>>> OK, I can't by inspection or by test see any performance
>>>>> differences between the 2 implementations (in fact,
>>>>> the older one, in some benchmarks, was slower due to
>>>>> the string operations in the critical path)...
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> On Nov 26, 2013, at 4:23 PM, Jim Jagielski wrote:
>>>>>
>>>>>> Thx... the key is httpd-2.4.6-uds-delta.patch and
>>>>>> that shows nothing, that I can see, which would
>>>>>> result in the "old" being faster than the "new"...
>>>>>> especially in the critical section where we do
>>>>>> the apr_sockaddr_info_get() stuff...
>>>>>>
>>>>>> On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri wrote:
>>>>>>
>>>>>>> I reapplied the patches in order to 2.4.6 before r1531340 was added to
>>>>>>> the proposal. Attached are the three diff's of use:
>>>>>>> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
>>>>>>> to (but not including) r1531340 sans the stuff that doesn't fit
>>>>>>> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
>>>>>>> first. Note that this doesn't include r1543174
>>>>>>> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
>>>>>>>
>>>>>>> --
>>>>>>> Daniel Ruggeri
>>>>>>>
>>>>>>> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
>>>>>>>> Sorry, I thought the diffs I sent off list were good enough. I'll have
>>>>>>>> to see if I even still have the original build lying around.
>>>>>>>> Effectively, I just took the list of patches in the backport proposal
>>>>>>>> and applied them one at a time to the 2.4.6 sources. If I can't find the
>>>>>>>> build, I'll do the same over and send that instead.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel Ruggeri
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
My test setup looks pretty much the same as yours: a simple
node.js server listening on the UDS path, but mine serves
just static content.
On Dec 2, 2013, at 7:04 PM, Daniel Ruggeri <DR...@primary.net> wrote:
> I had the same inclination as Cristophe but haven't been able to
> substantiate anything due to lack of time.... last week wasn't as kind
> to my free time as I had hoped. This would be very easy to tweak/test.
> Within the next day or two I should be able to get back in to perform
> some rebuilds and do more thorough testing and tampering as I squeeze
> time in between various work-related crises. Most of my testing is
> automated-ish, so turnaround from patch to test results is fairly quick.
>
> Jim, what does your test setup look like to measure performance delta?
> My setup is fairly simple with httpd on the frontend targeting a small
> Node.js backend application... I don't suspect the application is
> skewing the results because of how consistent the results have been, but
> I may just remove that from the equation to be absolutely sure.
>
> --
> Daniel Ruggeri
>
> On 12/2/2013 8:14 AM, Jim Jagielski wrote:
>> But from what I see, all of those are during non critical paths.
>> It's like when workers are being defined, initialized, etc and
>> that's only done during config or when added via balancer-manager.
>>
>> On Dec 2, 2013, at 8:09 AM, Marion et Christophe JAILLET <ch...@wanadoo.fr> wrote:
>>
>>> Hi,
>>>
>>>
>>> one of my thought was the change from
>>>
>>> worker->s->name
>>>
>>> to
>>>
>>> ap_proxy_worker_name(r->pool, worker)
>>>
>>> in logging function.
>>>
>>> ap_proxy_worker_name allocates memory in the pool and performs some operations on strings (apr_pstrcat).
>>>
>>>
>>> These operations are performed in all cases, even if DEBUG messages are not logged.
>>>
>>>
>>> I don't think this should have a real effect on performance. (If I remember well when I looked at it, there is no ap_log_error calls in sensitive code)
>>>
>>> Just to be sure, you could try to simplify ap_proxy_worker_name in Daniel's build to remove the apr_pstrcat and check performance with his build.
>>>
>>>
>>> Should you and Daniel have different logging levels, it could explain why you don't measure the same discrepancy.
>>>
>>>
>>>
>>> Just my 2 cents.
>>>
>>> If I have time, I'll give another look tonight.
>>>
>>>
>>> CJ
>>>
>>>
>>>
>>>
>>>> Message du 02/12/13 13:46
>>>> De : "Jim Jagielski"
>>>> A : dev@httpd.apache.org
>>>> Copie à :
>>>> Objet : Re: UDS Patch
>>>>
>>>> OK, I can't by inspection or by test see any performance
>>>> differences between the 2 implementations (in fact,
>>>> the older one, in some benchmarks, was slower due to
>>>> the string operations in the critical path)...
>>>>
>>>> Any ideas?
>>>>
>>>> On Nov 26, 2013, at 4:23 PM, Jim Jagielski wrote:
>>>>
>>>>> Thx... the key is httpd-2.4.6-uds-delta.patch and
>>>>> that shows nothing, that I can see, which would
>>>>> result in the "old" being faster than the "new"...
>>>>> especially in the critical section where we do
>>>>> the apr_sockaddr_info_get() stuff...
>>>>>
>>>>> On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri wrote:
>>>>>
>>>>>> I reapplied the patches in order to 2.4.6 before r1531340 was added to
>>>>>> the proposal. Attached are the three diff's of use:
>>>>>> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
>>>>>> to (but not including) r1531340 sans the stuff that doesn't fit
>>>>>> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
>>>>>> first. Note that this doesn't include r1543174
>>>>>> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
>>>>>>
>>>>>> --
>>>>>> Daniel Ruggeri
>>>>>>
>>>>>> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
>>>>>>> Sorry, I thought the diffs I sent off list were good enough. I'll have
>>>>>>> to see if I even still have the original build lying around.
>>>>>>> Effectively, I just took the list of patches in the backport proposal
>>>>>>> and applied them one at a time to the 2.4.6 sources. If I can't find the
>>>>>>> build, I'll do the same over and send that instead.
>>>>>>>
>>>>>>> --
>>>>>>> Daniel Ruggeri
>>>>>>
>>>>
>
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
I had the same inclination as Cristophe but haven't been able to
substantiate anything due to lack of time.... last week wasn't as kind
to my free time as I had hoped. This would be very easy to tweak/test.
Within the next day or two I should be able to get back in to perform
some rebuilds and do more thorough testing and tampering as I squeeze
time in between various work-related crises. Most of my testing is
automated-ish, so turnaround from patch to test results is fairly quick.
Jim, what does your test setup look like to measure performance delta?
My setup is fairly simple with httpd on the frontend targeting a small
Node.js backend application... I don't suspect the application is
skewing the results because of how consistent the results have been, but
I may just remove that from the equation to be absolutely sure.
--
Daniel Ruggeri
On 12/2/2013 8:14 AM, Jim Jagielski wrote:
> But from what I see, all of those are during non critical paths.
> It's like when workers are being defined, initialized, etc and
> that's only done during config or when added via balancer-manager.
>
> On Dec 2, 2013, at 8:09 AM, Marion et Christophe JAILLET <ch...@wanadoo.fr> wrote:
>
>> Hi,
>>
>>
>> one of my thought was the change from
>>
>> worker->s->name
>>
>> to
>>
>> ap_proxy_worker_name(r->pool, worker)
>>
>> in logging function.
>>
>> ap_proxy_worker_name allocates memory in the pool and performs some operations on strings (apr_pstrcat).
>>
>>
>> These operations are performed in all cases, even if DEBUG messages are not logged.
>>
>>
>> I don't think this should have a real effect on performance. (If I remember well when I looked at it, there is no ap_log_error calls in sensitive code)
>>
>> Just to be sure, you could try to simplify ap_proxy_worker_name in Daniel's build to remove the apr_pstrcat and check performance with his build.
>>
>>
>> Should you and Daniel have different logging levels, it could explain why you don't measure the same discrepancy.
>>
>>
>>
>> Just my 2 cents.
>>
>> If I have time, I'll give another look tonight.
>>
>>
>> CJ
>>
>>
>>
>>
>>> Message du 02/12/13 13:46
>>> De : "Jim Jagielski"
>>> A : dev@httpd.apache.org
>>> Copie à :
>>> Objet : Re: UDS Patch
>>>
>>> OK, I can't by inspection or by test see any performance
>>> differences between the 2 implementations (in fact,
>>> the older one, in some benchmarks, was slower due to
>>> the string operations in the critical path)...
>>>
>>> Any ideas?
>>>
>>> On Nov 26, 2013, at 4:23 PM, Jim Jagielski wrote:
>>>
>>>> Thx... the key is httpd-2.4.6-uds-delta.patch and
>>>> that shows nothing, that I can see, which would
>>>> result in the "old" being faster than the "new"...
>>>> especially in the critical section where we do
>>>> the apr_sockaddr_info_get() stuff...
>>>>
>>>> On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri wrote:
>>>>
>>>>> I reapplied the patches in order to 2.4.6 before r1531340 was added to
>>>>> the proposal. Attached are the three diff's of use:
>>>>> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
>>>>> to (but not including) r1531340 sans the stuff that doesn't fit
>>>>> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
>>>>> first. Note that this doesn't include r1543174
>>>>> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
>>>>>
>>>>> --
>>>>> Daniel Ruggeri
>>>>>
>>>>> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
>>>>>> Sorry, I thought the diffs I sent off list were good enough. I'll have
>>>>>> to see if I even still have the original build lying around.
>>>>>> Effectively, I just took the list of patches in the backport proposal
>>>>>> and applied them one at a time to the 2.4.6 sources. If I can't find the
>>>>>> build, I'll do the same over and send that instead.
>>>>>>
>>>>>> --
>>>>>> Daniel Ruggeri
>>>>>
>>>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
But from what I see, all of those are during non critical paths.
It's like when workers are being defined, initialized, etc and
that's only done during config or when added via balancer-manager.
On Dec 2, 2013, at 8:09 AM, Marion et Christophe JAILLET <ch...@wanadoo.fr> wrote:
> Hi,
>
>
> one of my thought was the change from
>
> worker->s->name
>
> to
>
> ap_proxy_worker_name(r->pool, worker)
>
> in logging function.
>
> ap_proxy_worker_name allocates memory in the pool and performs some operations on strings (apr_pstrcat).
>
>
> These operations are performed in all cases, even if DEBUG messages are not logged.
>
>
> I don't think this should have a real effect on performance. (If I remember well when I looked at it, there is no ap_log_error calls in sensitive code)
>
> Just to be sure, you could try to simplify ap_proxy_worker_name in Daniel's build to remove the apr_pstrcat and check performance with his build.
>
>
> Should you and Daniel have different logging levels, it could explain why you don't measure the same discrepancy.
>
>
>
> Just my 2 cents.
>
> If I have time, I'll give another look tonight.
>
>
> CJ
>
>
>
>
> > Message du 02/12/13 13:46
> > De : "Jim Jagielski"
> > A : dev@httpd.apache.org
> > Copie à :
> > Objet : Re: UDS Patch
> >
> > OK, I can't by inspection or by test see any performance
> > differences between the 2 implementations (in fact,
> > the older one, in some benchmarks, was slower due to
> > the string operations in the critical path)...
> >
> > Any ideas?
> >
> > On Nov 26, 2013, at 4:23 PM, Jim Jagielski wrote:
> >
> > > Thx... the key is httpd-2.4.6-uds-delta.patch and
> > > that shows nothing, that I can see, which would
> > > result in the "old" being faster than the "new"...
> > > especially in the critical section where we do
> > > the apr_sockaddr_info_get() stuff...
> > >
> > > On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri wrote:
> > >
> > >> I reapplied the patches in order to 2.4.6 before r1531340 was added to
> > >> the proposal. Attached are the three diff's of use:
> > >> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
> > >> to (but not including) r1531340 sans the stuff that doesn't fit
> > >> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
> > >> first. Note that this doesn't include r1543174
> > >> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
> > >>
> > >> --
> > >> Daniel Ruggeri
> > >>
> > >> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
> > >>> Sorry, I thought the diffs I sent off list were good enough. I'll have
> > >>> to see if I even still have the original build lying around.
> > >>> Effectively, I just took the list of patches in the backport proposal
> > >>> and applied them one at a time to the 2.4.6 sources. If I can't find the
> > >>> build, I'll do the same over and send that instead.
> > >>>
> > >>> --
> > >>> Daniel Ruggeri
> > >>
> > >>
> > >
> >
> >
Re: UDS Patch
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
Hi,
one of my thought was the change from
worker->s->name
to
ap_proxy_worker_name(r->pool, worker)
in logging function.
ap_proxy_worker_name allocates memory in the pool and performs some operations on strings (apr_pstrcat).
These operations are performed in all cases, even if DEBUG messages are not logged.
I don't think this should have a real effect on performance. (If I remember well when I looked at it, there is no ap_log_error calls in sensitive code)
Just to be sure, you could try to simplify ap_proxy_worker_name in Daniel's build to remove the apr_pstrcat and check performance with his build.
Should you and Daniel have different logging levels, it could explain why you don't measure the same discrepancy.
Just my 2 cents.
If I have time, I'll give another look tonight.
CJ
> Message du 02/12/13 13:46
> De : "Jim Jagielski"
> A : dev@httpd.apache.org
> Copie à :
> Objet : Re: UDS Patch
>
> OK, I can't by inspection or by test see any performance
> differences between the 2 implementations (in fact,
> the older one, in some benchmarks, was slower due to
> the string operations in the critical path)...
>
> Any ideas?
>
> On Nov 26, 2013, at 4:23 PM, Jim Jagielski wrote:
>
> > Thx... the key is httpd-2.4.6-uds-delta.patch and
> > that shows nothing, that I can see, which would
> > result in the "old" being faster than the "new"...
> > especially in the critical section where we do
> > the apr_sockaddr_info_get() stuff...
> >
> > On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri wrote:
> >
> >> I reapplied the patches in order to 2.4.6 before r1531340 was added to
> >> the proposal. Attached are the three diff's of use:
> >> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
> >> to (but not including) r1531340 sans the stuff that doesn't fit
> >> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
> >> first. Note that this doesn't include r1543174
> >> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
> >>> Sorry, I thought the diffs I sent off list were good enough. I'll have
> >>> to see if I even still have the original build lying around.
> >>> Effectively, I just took the list of patches in the backport proposal
> >>> and applied them one at a time to the 2.4.6 sources. If I can't find the
> >>> build, I'll do the same over and send that instead.
> >>>
> >>> --
> >>> Daniel Ruggeri
> >>
> >>
> >
>
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
OK, I can't by inspection or by test see any performance
differences between the 2 implementations (in fact,
the older one, in some benchmarks, was slower due to
the string operations in the critical path)...
Any ideas?
On Nov 26, 2013, at 4:23 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Thx... the key is httpd-2.4.6-uds-delta.patch and
> that shows nothing, that I can see, which would
> result in the "old" being faster than the "new"...
> especially in the critical section where we do
> the apr_sockaddr_info_get() stuff...
>
> On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri <DR...@primary.net> wrote:
>
>> I reapplied the patches in order to 2.4.6 before r1531340 was added to
>> the proposal. Attached are the three diff's of use:
>> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
>> to (but not including) r1531340 sans the stuff that doesn't fit
>> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
>> first. Note that this doesn't include r1543174
>> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
>>
>> --
>> Daniel Ruggeri
>>
>> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
>>> Sorry, I thought the diffs I sent off list were good enough. I'll have
>>> to see if I even still have the original build lying around.
>>> Effectively, I just took the list of patches in the backport proposal
>>> and applied them one at a time to the 2.4.6 sources. If I can't find the
>>> build, I'll do the same over and send that instead.
>>>
>>> --
>>> Daniel Ruggeri
>>
>> <httpd-2.4.6-uds-delta.patch><httpd-2.4.6-uds-new.patch><httpd-2.4.6-uds-original.patch>
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
Thx... the key is httpd-2.4.6-uds-delta.patch and
that shows nothing, that I can see, which would
result in the "old" being faster than the "new"...
especially in the critical section where we do
the apr_sockaddr_info_get() stuff...
On Nov 26, 2013, at 3:07 PM, Daniel Ruggeri <DR...@primary.net> wrote:
> I reapplied the patches in order to 2.4.6 before r1531340 was added to
> the proposal. Attached are the three diff's of use:
> httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
> to (but not including) r1531340 sans the stuff that doesn't fit
> httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
> first. Note that this doesn't include r1543174
> httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
>
> --
> Daniel Ruggeri
>
> On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
>> Sorry, I thought the diffs I sent off list were good enough. I'll have
>> to see if I even still have the original build lying around.
>> Effectively, I just took the list of patches in the backport proposal
>> and applied them one at a time to the 2.4.6 sources. If I can't find the
>> build, I'll do the same over and send that instead.
>>
>> --
>> Daniel Ruggeri
>
> <httpd-2.4.6-uds-delta.patch><httpd-2.4.6-uds-new.patch><httpd-2.4.6-uds-original.patch>
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
I reapplied the patches in order to 2.4.6 before r1531340 was added to
the proposal. Attached are the three diff's of use:
httpd-2.4.6-uds-original.patch - Everything in the backport proposal up
to (but not including) r1531340 sans the stuff that doesn't fit
httpd-2.4.6-uds-new.patch - The 2.4 patch proposed with r1511313 applied
first. Note that this doesn't include r1543174
httpd-2.4.6-uds-delta.patch - The delta between the two modified trees
--
Daniel Ruggeri
On 11/22/2013 5:27 PM, Daniel Ruggeri wrote:
> Sorry, I thought the diffs I sent off list were good enough. I'll have
> to see if I even still have the original build lying around.
> Effectively, I just took the list of patches in the backport proposal
> and applied them one at a time to the 2.4.6 sources. If I can't find the
> build, I'll do the same over and send that instead.
>
> --
> Daniel Ruggeri
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
Sorry, I thought the diffs I sent off list were good enough. I'll have
to see if I even still have the original build lying around.
Effectively, I just took the list of patches in the backport proposal
and applied them one at a time to the 2.4.6 sources. If I can't find the
build, I'll do the same over and send that instead.
--
Daniel Ruggeri
On 11/22/2013 10:38 AM, Jim Jagielski wrote:
> Any luck with generating the diff yet?
>
> On Nov 19, 2013, at 3:08 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> The main thing is that it would be interesting to see
>> the diffs between '2.4.6 w the (several) originally proposed UDS patches applied in order'
>> and '2.4.6 w proposed backport'...
>>
>> Those diffs should show just the differences between the UDS implementations...
>>
>> On Nov 19, 2013, at 2:51 PM, Daniel Ruggeri <DR...@primary.net> wrote:
>>
>>> Yes, agreed. Not sure if I made it clear, but I did apply r1511313 for
>>> the tests I did today (but not the one from yesterday).
>>>
>>> Of the several emails sent, the following have been tested:
>>> 2.4.6 w the (several) originally proposed UDS patches applied in order
>>> 2.4.6 w proposed backport (the 2 chunks around the DNS changes fail to
>>> apply since they do not exist in 2.4.6)
>>> 2.4.6 w r1511313 + proposed backport + r1543174
>>>
>>> I DID double check that the machine wasn't requesting DNS lookups for
>>> the socket name or anything strange against the DNS server - but that
>>> was only for the test I ran today.
>>>
>>> --
>>> Daniel Ruggeri
>>>
>>> On 11/19/2013 1:43 PM, Jim Jagielski 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.
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
Any luck with generating the diff yet?
On Nov 19, 2013, at 3:08 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> The main thing is that it would be interesting to see
> the diffs between '2.4.6 w the (several) originally proposed UDS patches applied in order'
> and '2.4.6 w proposed backport'...
>
> Those diffs should show just the differences between the UDS implementations...
>
> On Nov 19, 2013, at 2:51 PM, Daniel Ruggeri <DR...@primary.net> wrote:
>
>> Yes, agreed. Not sure if I made it clear, but I did apply r1511313 for
>> the tests I did today (but not the one from yesterday).
>>
>> Of the several emails sent, the following have been tested:
>> 2.4.6 w the (several) originally proposed UDS patches applied in order
>> 2.4.6 w proposed backport (the 2 chunks around the DNS changes fail to
>> apply since they do not exist in 2.4.6)
>> 2.4.6 w r1511313 + proposed backport + r1543174
>>
>> I DID double check that the machine wasn't requesting DNS lookups for
>> the socket name or anything strange against the DNS server - but that
>> was only for the test I ran today.
>>
>> --
>> Daniel Ruggeri
>>
>> On 11/19/2013 1:43 PM, Jim Jagielski 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.
>>
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
The main thing is that it would be interesting to see
the diffs between '2.4.6 w the (several) originally proposed UDS patches applied in order'
and '2.4.6 w proposed backport'...
Those diffs should show just the differences between the UDS implementations...
On Nov 19, 2013, at 2:51 PM, Daniel Ruggeri <DR...@primary.net> wrote:
> Yes, agreed. Not sure if I made it clear, but I did apply r1511313 for
> the tests I did today (but not the one from yesterday).
>
> Of the several emails sent, the following have been tested:
> 2.4.6 w the (several) originally proposed UDS patches applied in order
> 2.4.6 w proposed backport (the 2 chunks around the DNS changes fail to
> apply since they do not exist in 2.4.6)
> 2.4.6 w r1511313 + proposed backport + r1543174
>
> I DID double check that the machine wasn't requesting DNS lookups for
> the socket name or anything strange against the DNS server - but that
> was only for the test I ran today.
>
> --
> Daniel Ruggeri
>
> On 11/19/2013 1:43 PM, Jim Jagielski 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.
>
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
Yes, agreed. Not sure if I made it clear, but I did apply r1511313 for
the tests I did today (but not the one from yesterday).
Of the several emails sent, the following have been tested:
2.4.6 w the (several) originally proposed UDS patches applied in order
2.4.6 w proposed backport (the 2 chunks around the DNS changes fail to
apply since they do not exist in 2.4.6)
2.4.6 w r1511313 + proposed backport + r1543174
I DID double check that the machine wasn't requesting DNS lookups for
the socket name or anything strange against the DNS server - but that
was only for the test I ran today.
--
Daniel Ruggeri
On 11/19/2013 1:43 PM, Jim Jagielski 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.
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
Nope... nevermind. You said it happened w/ 2.4.6 so that's
moot.
On Nov 19, 2013, at 2:43 PM, Jim Jagielski <ji...@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 <ji...@jaguNET.com> wrote:
>
>> That's just weird...
>>
>> On Nov 19, 2013, at 11:33 AM, Daniel Ruggeri <DR...@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
>>>>
>>>
>>
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ji...@jaguNET.com> wrote:
> That's just weird...
>
> On Nov 19, 2013, at 11:33 AM, Daniel Ruggeri <DR...@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
>>>
>>
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
That's just weird...
On Nov 19, 2013, at 11:33 AM, Daniel Ruggeri <DR...@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
>>
>
Re: UDS Patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
Can you provide a 'diff -u' of the 2 2.4.6 sources?
Thx!
On Nov 19, 2013, at 11:33 AM, Daniel Ruggeri <DR...@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
>>
>
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
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
>
Re: UDS Patch
Posted by Daniel Ruggeri <DR...@primary.net>.
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