因此我创建了一个简单的文件，ab.htm，其中只有“测试”。
ab -n 1000 -c 10 http://www.domain.com/ab.htm
给我 15400req/sec
和
ab -n 1000 -c 10 https://www.domain.com/ab.htm
给我 390req/sec
如果我添加 -k Keep-Alive 标志，它会回到 ~10,000。但这不是解决方案，如果我有 1,000 个并发用户，他们不会全部共享同一个连接……
这是在 4GB Centos 6 VPS、nginx 1.5.6 上。
我也在 1、100 和 1000 的并发数下尝试过，并得到了类似的结果。
我原本以为它会慢一些，但没想到慢了四十倍……这是正常的吗，还是出了什么严重问题？如果这是正常的，我能做些什么来改善这种情况——我想是使用更弱的密码等等？
是的，我知道这只是整个难题中的一小部分，与脚本和数据库负载相比，这相对微不足道。但我仍然希望至少知道这是正常的。
谢谢
附加信息：
- CentOS 6.4
- 英特尔 E5-2640 CPU
- Xen VPS（我认为是在 HP DL380p Gen8 Proliant 服务器上）
- 4GB 内存
版本等：
uname -a
Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP 2013 年 8 月 28 日星期三 17:19:38 UTC x86_64 x86_64 x86_64 GNU/Linux
openssl version
OpenSSL 1.0.1e 2013 年 2 月 11 日
nginx -V
nginx 版本：nginx/1.5.6 由 gcc 4.4.7 20120313（Red Hat 4.4.7-3）(GCC) 构建 TLS SNI 支持启用配置参数：--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 --使用-http_ssl_module --使用-http_realip_module --使用-http_addition_module --使用-http_sub_module --使用-http_dav_module --使用-http_flv_module --使用-http_mp4_module --使用-http_gunzip_module --使用-http_gzip_static_module --使用-http_random_index_module --使用-http_secure_link_module --使用-http_stub_status_module --使用-mail --使用-mail_ssl_module --使用-file-aio --使用-http_spdy_module
答案1
可以预料到会出现明显的减速，但 300 rps 实在是太慢了；我最近做了一些测试，这些就是我的结果，可以给你一些数字和关系：
- http: ~ 30.000 rps
- 无 keepalive 的 https：~ 9.000 rps
- https 与 keepalive 连接：~ 18.000 rps
你需要做什么：
- 在 nginx.conf 中调整正确的工作进程数量（工作进程 == 处理器数量）
- 使能够ssl_session_cache 共享
- 测试不同密码套件的性能（我的网站有待确定）
- 查看本指南更多基于 nginx 的 ssl + perf-tuning-infos
我期望 Apache 能达到 390/rps...SCNR:)