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 > <christophe.jail...@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 >>>>> >>>
