4 ms·

Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/

by Sukera 7y ago

deleted 7y ago
[deleted]
namibj 7y ago
Oh, yeah, for good clients it's totally fine. But e.g. a machine I'll try an http benchmark on in a couple hours (2 cires; 4780 BogoMIPS each) only managed 4177 ops/s using the fastest-available curve X25519 with openssl speed ecdh gatling -V -n -p 80 -u nobody I know this is somewhat extreme, but on a cpu that was about 30% faster I got 40k rps for small files using the kernel's loopback, which is where the cpu spent most of it's time. Feel free to try.
- dependenttypes 7y ago
  This should happen only during the handshake though.
kevingadd 7y ago
In my testing for high-throughput scenarios like copies over ssh/rsync/https/smb (i tried them all) in every case encryption was a big hit to throughput. hardware assistance (built into the CPU) helped a lot but it was still a massive boost to shut off encryption - saving literal minutes on every bulk transfer, multiple transfers per day. For the average case it probably doesn't matter, and you can optimize it, but I think it is totally understandable that the average novice could end up with bad https performance if only because the defaults are bad or they made a mistake. If hardware assist for the handshake and/or transfer crypto is shut off (or unavailable, on lower-spec CPUs) your perf is going to tank real hard. I ended up using ssh configured to use the weakest (fastest) crypto possible, because disabling crypto entirely was no longer an option. I controlled the entire network end to end so no real risk there - but obviously a dangerous tool to provide for insecure links. Also worth keeping in mind that there are production scenarios now where people are pushing 1gb+ of data to all their servers on every deploy - iirc among others when Facebook compiles their entire site the executable is something like a gigabyte that needs to be pushed to thousands of frontends. If you're doing that over encrypted ssh you're wasting cycles which means wasting power and you're wasting that power on thousands of machines at once. Same would apply if the nodes pull the new executable down over HTTPS.
- acdha 7y ago
  How long ago was this — and how fast was your network? On hardware less than a decade old you shouldn’t be seeing that unless you’re talking about 10+Gb networking.
  - kevingadd 7y ago
    A year ago in my development VMs, it was the difference between like 40MB/s throughput and 200+

Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/

by Sukera 7y ago

Do you have a source on that? Quite a few people seem to disagree: https://istlsfastyet.com/ https://istlsfastyet.com/

deleted 7y ago

[deleted]

namibj 7y ago

Oh, yeah, for good clients it's totally fine. But e.g. a machine I'll try an http benchmark on in a couple hours (2 cires; 4780 BogoMIPS each) only managed 4177 ops/s using the fastest-available curve X25519 with openssl speed ecdh gatling -V -n -p 80 -u nobody I know this is somewhat extreme, but on a cpu that was about 30% faster I got 40k rps for small files using the kernel's loopback, which is where the cpu spent most of it's time. Feel free to try.

dependenttypes 7y ago
This should happen only during the handshake though.

kevingadd 7y ago

In my testing for high-throughput scenarios like copies over ssh/rsync/https/smb (i tried them all) in every case encryption was a big hit to throughput. hardware assistance (built into the CPU) helped a lot but it was still a massive boost to shut off encryption - saving literal minutes on every bulk transfer, multiple transfers per day. For the average case it probably doesn't matter, and you can optimize it, but I think it is totally understandable that the average novice could end up with bad https performance if only because the defaults are bad or they made a mistake. If hardware assist for the handshake and/or transfer crypto is shut off (or unavailable, on lower-spec CPUs) your perf is going to tank real hard. I ended up using ssh configured to use the weakest (fastest) crypto possible, because disabling crypto entirely was no longer an option. I controlled the entire network end to end so no real risk there - but obviously a dangerous tool to provide for insecure links. Also worth keeping in mind that there are production scenarios now where people are pushing 1gb+ of data to all their servers on every deploy - iirc among others when Facebook compiles their entire site the executable is something like a gigabyte that needs to be pushed to thousands of frontends. If you're doing that over encrypted ssh you're wasting cycles which means wasting power and you're wasting that power on thousands of machines at once. Same would apply if the nodes pull the new executable down over HTTPS.

acdha 7y ago
How long ago was this — and how fast was your network? On hardware less than a decade old you shouldn’t be seeing that unless you’re talking about 10+Gb networking.
- kevingadd 7y ago
  A year ago in my development VMs, it was the difference between like 40MB/s throughput and 200+