4 ms·

The post didn't mention if ssl_session_cache was enabled in the nginx config or not. In fact, I didn't see any configs posted. :( Also, the article author appa

The post didn't mention if ssl_session_cache was enabled in the nginx config or not. In fact, I didn't see any configs posted. :( 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/9d9b52b7d3ce90fa84c67eca261b087336233775 https://github.com/bumptech/stud/commit/9d9b52b7d3ce90fa84c6...

jamwt 15y ago
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.
- jamwt 15y ago
  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.
  - stock_toaster 15y ago
    I really agree with this. I think keeping stud as simple as possible is a great goal.
  - sciurus 15y ago
    Could someone link to a description of the PROXY protocol?
    - stock_toaster 15y ago
      http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
- seiji 15y ago
  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.
seiji 15y ago
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.

jamwt 15y ago

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.

jamwt 15y ago
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.
- stock_toaster 15y ago
  I really agree with this. I think keeping stud as simple as possible is a great goal.
- sciurus 15y ago
  Could someone link to a description of the PROXY protocol?
  - stock_toaster 15y ago
    http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
seiji 15y ago
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.

seiji 15y ago

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.