Lukas Tribus Wrote:
---
> > 4 threads and 4 CPU (both for apache and nginx) with 100% CPU load
> on test
> > So, what's the answer now about the http/https (4600/550) ratio for
> the
> > specific case I presented?
>
> It should perform the same a
> 4 threads and 4 CPU (both for apache and nginx) with 100% CPU load on test
> So, what's the answer now about the http/https (4600/550) ratio for the
> specific case I presented?
It should perform the same as Apache in this case.
___
nginx mailing list
Lukas Tribus Wrote:
---
> That depends: how many nginx workers do you have compared to
> how many apache threads and how does your per-core CPU load
> look like when benchmarking?
> ___
> nginx mailing l
> I agree but I think that separate/different simultaneous users won't use a
> common connection so for this very specific scenario keep-alive won't
> matter. Of course for every individual user keep-alive will matter but this
> aspect for the moment I won't to ignore in testing.
It does matter, a
Lukas Tribus Wrote:
---
> > I'll do it but I guess the test will no longer be so relevant
> because I want
> > to simulate different users.
>
> Real user/browser DO keep-alive. ...
I agree but I think that separate/different simultaneous users
> ab does not support TLS tickets (you can verify this with wireshark), so even
> if
> you do enable HTTP keepalive, the full TLS handshake has to be performed for
> each request.
>
> it's a poor tool to measure total potential throughout of HTTPS servers.
Now that you mention it I kind of remem
> Enabling keepalive on ab is one of the things you can do. I don't know
> ab, so not sure if there is a better way. I also do not know if ab supports
> SSL session caching or TLS tickets, which you would have to keep in
> mind when benchmarking.
ab does not support TLS tickets (you can verify th
> I'll do it but I guess the test will no longer be so relevant because I want
> to simulate different users.
Real user/browser DO keep-alive. Sendings thousands of requests per
second in dedicated TLS session is not what you would see in real life
from real users.
> Anyway, the question is in
Just to help those not knowing about -k option:
-k Enable the HTTP KeepAlive feature, i.e., perform multiple requests
within one HTTP session. Default is no KeepAlive
I'll do it but I guess the test will no longer be so relevant because I want
to simulate different users.
Anyway, the question
> I test on running ab command on the same host as nginx is.
Did you test with -k (keepalive) on or off?
Without -k means that ab will do handshake every time and you will be limited
by cpu and depending on the chosen cipher the performance (requests per second)
can vary a lot.
rr
I used https://mozilla.github.io/server-side-tls/ssl-config-generator/ in
order to configure the ssl part for my nginx:
https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.11.3&openssl=1.0.2g&hsts=yes&profile=intermediate
but with no OCSP Stapling, ssl_trusted_certificate
Oh, I forgot to mention that the setup included also:
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,270898,270900#msg-270900
___
nginx mailing list
nginx@nginx.org
http://mailman.ng
Because you have the TLS handshake that has to be done which is CPU bound
Try change things like ssl_ciphers (to something faster), and use
ssl_session_cache/
--
Best Regards,
Lucas Rolff
gigihc11 wrote:
Hi, I have:
nginx 1.11.3
Ubuntu 16.04.1 LTS
openssl 1.0.2g-1ubuntu4.5 amd64
libssl1.0.0
Hi, I have:
nginx 1.11.3
Ubuntu 16.04.1 LTS
openssl 1.0.2g-1ubuntu4.5 amd64
libssl1.0.0:amd64 1.0.2g-1ubuntu4.5
weak CPU: N3150
16 GB RAM
with this test-setup:
open_file_cache max=1000 inactive=360s;
open_file_cache_valid 30s;
I test on running ab command on the same host as nginx is.
For a 1.6K
14 matches
Mail list logo
