Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


How to measure how many new TLS connections asking just homepage VPS can handle per second?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

How to measure how many new TLS connections asking just homepage VPS can handle per second?

umiumi Member

tested from another vps (E5-2690 v2 @ 3.00GHz) 15ms away:

homepage with static brotli compression:
openssl s_time -new -connect www.yourserverdomain.com:443 -cipher AES128-GCM-SHA256 -www index.html.br
306 connections in 0.63s; 485.71 connections/user sec, bytes read 11249784
306 connections in 31 real seconds, 36764 bytes read per connection

uncompressed homepage:
openssl s_time -new -connect www.yourserverdomain.com:443 -cipher AES128-GCM-SHA256 -www index.html
213 connections in 0.82s; 259.76 connections/user sec, bytes read 51987336
213 connections in 31 real seconds, 244072 bytes read per connection

What the hell is that mean?

I think this server vps can handle a lot more connections.
(server vps cpu (E5-2660 v2 @ 2.20GHz) usage during tests is just 2-4%)

Any thoughts?

Comments

  • May be loader.io can help you.

    Thanked by 1umi
  • jsgjsg Member, Resident Benchmarker
    • the slow (high compute cost) is the SE (session establishment) and KEX (key exchange) which uses asymmetric crypto.
    • the (usually) biggest part, the transmission of payload data, is much, much faster because it's symmetric crypto based (in your case above AES-128 GCM)
    • The question "how many new connections" is virtually completely based on the SE+KEX part.
    • You did not specify how the KEX shall be working, so OpenSSL simply uses whatever happens to be the default.
      More precisely the server offers a bunch of algorithms (and variants) that happen to be configured (e.g. by the distro) out of which the client chooses one out of a bunch of algorithms (and variants) that happen to be configured.

    • Both the server and the client may or may not be multithreaded and hence use only one of the available cores or multiple ones - which is very performance relevant. Important note: multi-threading on OpenSSL pre 1.1.x are to be considered very questionable and the current versions shouldn't be trusted either and should be considered shaky.

    So, have a look at your versions and configs. Usually the default ones are not exactly optimal, neither wrt to performance nor wrt security.

    Thanked by 1umi
  • What is your web server?
    How do you run load testing?

    I recommend to test with WRK for load testing.

    Nginx should be able to respond a simple html file really fast, several thousands of query per second for a static html file

  • jsgjsg Member, Resident Benchmarker

    @angelius said:
    What is your web server?
    How do you run load testing?

    I recommend to test with WRK for load testing.

    Nginx should be able to respond a simple html file really fast, several thousands of query per second for a static html file

    Pardon me but that's clueless BS. Whether static or dynamic files/content is requested/served is utterly meaningless. The bottleneck in a SSL/TLS session is the SE and KEX - which is completely decoupled from the type of content requested/served.

  • umiumi Member

    True. Even tiny VPS can easily saturate gigabit pipe with almost any modern webserver. The problem is that TLS handshakes are quite slow. Is there a tool that says: this pair of client-server can perform up to say 1200 TLSv1.3 handshakes per second if they about to use all resources available?

Sign In or Register to comment.