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 <drugg...@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 >> <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 >>>>>> >>>> >
