2

So I've created a simple file, ab.htm, with just "test" in it.

ab -n 1000 -c 10 http://www.domain.com/ab.htm

gives me 15400req/sec

and

ab -n 1000 -c 10 https://www.domain.com/ab.htm

gives me 390req/sec

If I add the -k Keep-Alive flag, it comes back up to ~10,000. But that's not a solution, if I get 1,000 concurrent users they're not all going to share the same connection...

This is on a 4GB Centos 6 VPS, nginx 1.5.6.

I tried it at concurrencies of 1, 100 & 1000 too and got similar results.

I was expecting it to be slower, but not FORTY times slower.... is this normal, or has something gone horribly wrong? If it is normal, what can I do to improve the situation - weaker cyphers etc I guess?

And yes, I appreciate that this is a tiny part of the puzzle, and relatively insignificant compared to scripting and database loads. But still, I'd like to at least know that it's normal.

Thanks


Additional info:

  • CentOS 6.4
  • Intel E5-2640 CPU
  • Xen VPS (on a HP DL380p Gen8 Proliant Server, I think)
  • 4GB ram

Versions etc:

uname -a

Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

openssl version

OpenSSL 1.0.1e 11 Feb 2013

nginx -V

nginx version: nginx/1.5.6 built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --http-log-path=/var/log/nginx/access.log --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module

9
  • can you add your ssl_config, esp. cipher_suites? Oct 9, 2013 at 7:41
  • Other than the SSL certs & private key, I have nothing configured at all. Just letting it run with its defaults for the time being.
    – Codemonkey
    Oct 9, 2013 at 10:26
  • Which, when I browse to the site in Chrome, tells me this: "encrypted with 256-bit encryption. The connection uses TLS1.2. The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and DHE_RSA as the key exchange mechanism.
    – Codemonkey
    Oct 9, 2013 at 10:28
  • no cipher_suites? Oct 9, 2013 at 14:21
  • I didn't have any set. I do now, and it's made very little difference, regardless of which ciphers I pick. Next idea?
    – Codemonkey
    Oct 9, 2013 at 15:18

1 Answer 1

1

a significant slowdown is to be expected but 300 rps is too slow; i did some tests recently and those are my results, to give you some numbers and relations:

  • http: ~ 30.000 rps
  • https w/out keepalive: ~ 9.000 rps
  • https w/ keepalive: ~ 18.000 rps

what your need to do:

  • tune the right numbers of workers in nginx.conf (workes == numbers of processors)
  • enable ssl_session_cache shared
  • test different cipher-suites for performance (tbd from my site)
  • check out this guide for more nginx-based ssl + perf-tuning-infos

390/rps i'd expect from apache ... SCNR :)

4
  • 1) Already set workers to cores (6)
    – Codemonkey
    Oct 9, 2013 at 10:53
  • 2) Setting "ssl_session_cache shared:SSL:10m;" and restarting nginx made negligible difference.
    – Codemonkey
    Oct 9, 2013 at 10:53
  • ok, then i'd suggest cipher-tuning, and you might want to check with ssllabs.com. and please retest with -c 100 Oct 9, 2013 at 14:22
  • I've tried a whole bunch of different ciphers now, including some of the weakest ones. They make very little difference, ranging from 350 to 400 req/sec. This tells me that the problem isn't with the cipher, but something else that's causing a big delay...
    – Codemonkey
    Oct 9, 2013 at 15:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .