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 <[email protected]> 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 >>> <[email protected]> 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 : [email protected] >>>>> 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
