Hitch is 1.5x - 2x slower than Cowboy. Unfortunately it only supports one upstream backend server at a time. Thus, we can’t serve our two webapps on port 443. Another constraint is that our two webapps has to run on the same host (a customer’s requirement).
Finally the system is not even under load. Maximum of 10 files upload per hour.
Forgot to mention our config:
1. Erlang 22.1.6
2. Linux kernel 184.108.40.206 / Ubuntu LTS 18.10 x86_64
3. Physical machine: 32gB of RAM, 8-Cores Intel Xeon CPU E3-1270 email@example.comGHz
4. Nginx V1.14.0
5. Sysctl tuned by our engineers for handle fast TCP connections with enough open files limits (ulimit -n: 200000)
Le sam. 9 nov. 2019 à 03:58, Mikael Karlsson <[hidden email]> a écrit :
Did you try with proxy_buffering set to on, and/or changing the proxy_buffer_size?
Re: snit (SNI Termination Library) to replace Nginx
On Sat, 9 Nov 2019, at 07:22, Frank Muller wrote:
> We mainly upload large files (20mB to 100mB) to our two webapps behind Nginx.
> ssl_prefer_server_ciphers on;
- use TLS1.3 if you can - most of the decisions have been made for you
- ensure your cipher choice is hardware accelerated in your openssl
- look at actual network traffic to see if there's any issues there
- no easy answers, benchmark your setup
I hope this helps point you in the right direction.
"SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of
memory per connection and less than 2% of network overhead."
It should be possible to transfer traffic over TLS at rates significantly
faster than what you're reporting, obviously. However, I would be surprised
if nginx itself is the problem, given netflix can saturate their pipes with
nginx, admittedly with a lot of tweaking ,  and a custom FreeBSD build.
I would first look to see if you can restrict your ciphers to provide better
performance for your hardware, and highly recommend capturing data with
tcpdump & wireshark to do some network level analysis. This will vary a lot
depending on what control you have over client TLS capabilities , and
if you have OpenSSL 1.1.x available, and perhaps http2 on clients also.
Intel's notes from 2016  show a noticeable difference between algorithms
so you need to benchmark your load on your hardware.
Personally, for TLS termination I prefer haproxy but all of hitch, nginx,
snit, haproxy should be able to achieve similar results. is interesting
but 2.x haproxy handles multiple processes itself.
>We’re facing a performance issue with Nginx used as TLS Termination.
>Nginx is in front of our two Erlang webapps. Both running on the same
>machine, and both based on Cowboy 2.7.0.
> directly accessing the two webapps (plain HTTP) is fast enough for us,
>and Cowboy is doing just great.
> accessing any of the two apps with Nginx (HTTPS) is 3x-5x slower than
Chances are you might have some tuning issues regarding TLS,
If you nevertheless decide to benchmark snit and have it replace nginx,
be aware that snit only handles TLS termination with SNI, and is not a
general proxy; it was in fact a component that was used along with a
router that was built on top of vegur (https://github.com/heroku/vegur)
As such, it wouldn't replace what nginx does for you. If you decide to
use snit, I would recommend using it to front the nginx instances you
would have anyway, to see if it can terminate TLS faster. But nginx does
other stuff, such as request buffering and offering forms of overload
protection your app would no longer have without it (or another actual
proxy server) offering protection.
Another thing you can do if you find that snit gives you good
performance is look with tcpdump or wireshark and see what TLS options,
extensions, ciphersuites, and elliptic curves are being chosen. Most of
the heavy cryptographic lifting is done by underlying C libraries, and
until you get similar priorities chosen by both servers, the comparison
will not be equitable.
If the settings are the same, then you are starting to compare apples
with apples and the higher-level code may be making a difference.