Hello! On Sun, Nov 16, 2014 at 05:07:12PM +0800, Sepherosa Ziehau wrote:
> Heh, I never made that patch for Linux and I don't use Linux ;). And > since Linux does not inherit sockets, once SO_REUSEPORT listen socket > is closed you should have seen the strange timeout as you have > described (as I had told you linux missing the socket inheritance > feature). On DFLY, we could max out all CPUs w/o problem and have no > strange timeout or connection drops when doing binary upgrading. > > Well, at least your test result suggests for SO_REUSEPORT, different > OSes may need OS-specific implementation eventually to achieve better > performance or keep binary upgrading works. You probably could keep > your patch as Linux specific patch as what we do for the dports. I would rather suggest that tests are flawed and needs to be redone from scratch by someone who will be able to share testing details. > > Best Regards, > sephe > > > On Fri, Oct 31, 2014 at 6:24 AM, Lu, Yingqi <yingqi...@intel.com> wrote: > > Hi All, > > > > We tested the dragonfly approach on Linux (RHEL 6.5 with kernel 3.13.9). We > > used the same testing environment for both our patch and the dragonfly > > patch. Here is what we found: > > > > 1. Our patch has 36% better performance (operations/sec) comparing to > > dragonfly patch. > > 2. Our patch has 53% lower response time comparing to dragonfly approach > > even at 36% higher throughput level. > > 3. Our patch can scale the CPU utilization and frequency to the max > > capacity while dragonfly patch cannot. > > 4. Our patch does not have any issues with "upgrade binary on the fly". > > However, dragonfly patch creates a spike in the response time during the > > upgrade. It also has lots of connection timeouts/losses with high load. > > > > Above findings are based on Linux OS. > > > > Thanks, > > Yingqi > > > > -----Original Message----- > > From: nginx-devel-boun...@nginx.org [mailto:nginx-devel-boun...@nginx.org] > > On Behalf Of Lu, Yingqi > > Sent: Wednesday, October 08, 2014 11:24 AM > > To: nginx-devel@nginx.org > > Subject: RE: [Patch] SO_REUSEPORT support from master process > > > > One more comment from me: duplicate listen sockets in kernel is not a > > trivia thing to do and it may take long time before people can see it. > > Addressing it Nginx may not be as ideal as in kernel, but at least user can > > see the performance improvement sooner. In fact, we see up to 48% > > performance improvement on modern Intel system. Just my two cents. > > > > Again, thanks very much for everyone for helping us review this. > > > > Thanks, > > Yingqi > > > > -----Original Message----- > > From: nginx-devel-boun...@nginx.org [mailto:nginx-devel-boun...@nginx.org] > > On Behalf Of Lu, Yingqi > > Sent: Wednesday, October 08, 2014 10:05 AM > > To: nginx-devel@nginx.org > > Subject: RE: [Patch] SO_REUSEPORT support from master process > > > > Hi Maxim, > > > > Thanks for letting us know. > > > > Our updated patch is located at > > http://forum.nginx.org/read.php?29,253446,253446#msg-253446 > > > > It supposes to address all the style issues and fixes the restart and > > binary upgrade issues. This is just a FYI in case you are not aware of. > > > > Thanks, > > Yingqi > > > > -----Original Message----- > > From: nginx-devel-boun...@nginx.org [mailto:nginx-devel-boun...@nginx.org] > > On Behalf Of Maxim Dounin > > Sent: Wednesday, October 08, 2014 5:59 AM > > To: nginx-devel@nginx.org > > Subject: Re: [Patch] SO_REUSEPORT support from master process > > > > Hello! > > > > On Tue, Oct 07, 2014 at 07:32:08PM +0000, Lu, Yingqi wrote: > > > >> Dear All, > >> > >> It has been quiet for a while on this patch. I am checking to see if > >> there is any questions/feedbacks/concerns we need to address? > >> > >> Please let me know. Thanks very much for your help! > > > > Apart from style/coding issues, I disagree with the whole approach. > > > > As far as I understand the patch idea, it tries to introduce multiple > > listening sockets to avoid in-kernel lock contention. > > This is something that can be done completely in kernel though, and I see > > no reason to introduce any changes to nginx here. > > > > The approach previously discussed with Sepherosa Ziehau looks much more > > interesting. > > > > -- > > Maxim Dounin > > http://nginx.org/ > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > _______________________________________________ > > nginx-devel mailing list > > nginx-devel@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > -- > Tomorrow Will Never Die > > _______________________________________________ > nginx-devel mailing list > nginx-devel@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
