Re:Nginx sucks at SSL, here's what to do instead
by seiji on Monday July 11, 2011 @06:12PM
(#2752699)
I hear the same performance happens with our without the session cache enabled (for benchmarks). The http(s) benchmarking tools don't resume sessions. It's simulating a horde of new clients who never come back or request other resources.
It would be interesting to see stud with a session cache too.
Re:Nginx sucks at SSL, here's what to do instead
by jamwt on Monday July 11, 2011 @04:20PM
(#2752337)
I'm reading over Matt's work carefully, but my initial inclination is not to merge the bulk of this into stud mainline. I'd rather keep stud simple and protocol-naive and have HAProxy do the HTTP work.
Re:Nginx sucks at SSL, here's what to do instead
by jamwt on Monday July 11, 2011 @04:36PM
(#2752414)
Which is to say indirectly that I think the right answer is for nginx (and daemons generally) to support the PROXY protocol, or some other agreed-upon standard for a naive upstream proxy to indicate host/port information.
Re:Nginx sucks at SSL, here's what to do instead
by sciurus on Monday July 11, 2011 @10:30PM
(#2753299)
Could someone link to a description of the PROXY protocol?
Re:Nginx sucks at SSL, here's what to do instead
by stock_toaster on Tuesday July 19, 2011 @10:40PM
(#2784081)
Re:Nginx sucks at SSL, here's what to do instead
by stock_toaster on Monday July 11, 2011 @07:15PM
(#2752871)
I really agree with this.
I think keeping stud as simple as possible is a great goal.
Re:Nginx sucks at SSL, here's what to do instead
by seiji on Monday July 11, 2011 @06:41PM
(#2752791)
I'm reading over Matt's work carefully
Thanks for the consideration!
initial inclination is not to merge the bulk of this into stud mainline
I agree. The HTTP stuff is still too integrated. ifdefs are ugly.
The solution is to do what showed up when I was 99% done working on XFF -- the nice PROXY protocol addition. We just need to get PROXY support into nginx now to obviate my XFF machinations.
Also, the article author apparently added support to stud (in his own fork) for x-forward-for. I don't think this is required any longer, due to this fairly recent stud commit: https://github.com/bumptech/stud/commit/9d9b52b7d3ce90fa84c6...