g-wan – 再现performance主张

在Ubuntu 12.04 LTS下使用gwan_linux64-bit.tar.bz2解包并运行gwan

然后指向wrk(使用空文件null.html)

wrk --timeout 10 -t 2 -c 100 -d20s http://127.0.0.1:8080/null.html Running 20s test @ http://127.0.0.1:8080/null.html 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 11.65s 5.10s 13.89s 83.91% Req/Sec 3.33k 3.65k 12.33k 75.19% 125067 requests in 20.01s, 32.08MB read Socket errors: connect 0, read 37, write 0, timeout 49 Requests/sec: 6251.46 Transfer/sec: 1.60MB 

性能非常差,实际上似乎有某种巨大的延迟问题。 在testing期间,gwan是200%繁忙,wrk是67%繁忙。

指向nginx,wrk是200%忙,nginx是45%忙:

 wrk --timeout 10 -t 2 -c 100 -d20s http://127.0.0.1/null.html Thread Stats Avg Stdev Max +/- Stdev Latency 371.81us 134.05us 24.04ms 91.26% Req/Sec 72.75k 7.38k 109.22k 68.21% 2740883 requests in 20.00s, 540.95MB read Requests/sec: 137046.70 Transfer/sec: 27.05MB 

指向nginx的weighttpd可以得到更快的结果:

 /usr/local/bin/weighttp -k -n 2000000 -c 500 -t 3 http://127.0.0.1/null.html weighttp - a lightweight and simple webserver benchmarking tool starting benchmark... spawning thread #1: 167 concurrent requests, 666667 total requests spawning thread #2: 167 concurrent requests, 666667 total requests spawning thread #3: 166 concurrent requests, 666666 total requests progress: 9% done progress: 19% done progress: 29% done progress: 39% done progress: 49% done progress: 59% done progress: 69% done progress: 79% done progress: 89% done progress: 99% done finished in 7 sec, 13 millisec and 293 microsec, 285172 req/s, 57633 kbyte/s requests: 2000000 total, 2000000 started, 2000000 done, 2000000 succeeded, 0 failed, 0 errored status codes: 2000000 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 413901205 bytes total, 413901205 bytes http, 0 bytes data 

服务器是KVM下的虚拟8核专用服务器(裸机)

我在哪里开始寻找gwan在这个平台上遇到的问题?

我已经在同一个操作系统上testing了lighttpd,nginx和node.js,结果都是一样的。 服务器通过扩展的临时端口,增加限制,调整时间等等循环来调整。

11月7日更新:我们修复了G-WAN v4.11.7中的空文件问题,现在G-WAN的速度比Nginx快两倍(禁用www缓存)。

最近G-WAN的发布速度比Nginx的小大文件快,而G-WAN缓存在默认情况下是禁用的,以便于人们比较G-WAN与Nginx等其他服务器的比较。

Nginx有几个缓存功能(一个跳过stat()调用的fd cahe和一个基于memcached的模块),但两者都必须比G-WAN的本地缓存慢得多。

禁用缓存对于某些应用程序(如CDN)也是需要的。 其他应用程序(如AJAX应用程序)从G-WAN缓存功能中受益匪浅,因此即使在每个请求的基础上,也可以随时重新启用缓存。

希望这个澄清这个问题。


“再现业绩声明”

首先,由于上面记录不良的测试不使用相同的工具,也没有通过G-WAN测试获取的HTTP资源,因此标题是误导性的。

[*]你的nginx.conf文件在哪里? 这两个服务器的HTTP响应头是什么? 什么是你的“裸机” 8核CPU?

G-WAN测试基于ab.c ,由G-WAN小组编写的用于weighttp (由Lighttpd服务器团队制作的测试工具)的包装器,因为ab.c公开的信息更加丰富 。

其次,测试文件"null.html"是…一个空文件。

我们不会浪费时间讨论这种测试的不相关性( 您的网站提供了多少个空的HTML文件? ),但这可能是观察到的“糟糕的性能”的原因。

G-WAN没有被创建为服务于空文件(我们从来没有试过,也没有要求这样做)。 但是我们一定会添加这个功能来避免这样的测试造成的混乱。

正如你想要“检查声明”,我鼓励你用weighttp文件(一个100字节的文件,不可压缩的MIME类型)使用weighttp (在你的测试中最快的HTTP加载工具):在这里没有Gzip )。

对于非空文件,即使在独立测试中, Nginx也比G-WAN慢得多 。

我们到目前为止还不了解wrk ,但似乎是Nginx团队所做的工具:

“wrk是专门为了试图将nginx推向极限而在第一轮测试中被推到0.5Mr / s的。


更新(一天之后)

既然你不打算发布更多的数据,我们做到了:

  wrk weighttp ----------------------- ----------------------- Web server 0.html RPS 100.html RPS 0.html RPS 100.html RPS ---------- ---------- ------------ ---------- ------------ G-WAN 80,783.03 649,367.11 175,515 717,813 Nginx 198,800.93 179,939.40 184,046 199,075 

就像在你的测试中,我们可以看到weighttpweighttp

我们也可以看到G-WAN比Nginx都有更快的HTTP加载工具。

以下是详细的结果:


G-WAN

 ./wrk -c300 -d3 -t6 "http://127.0.0.1:8080/0.html" Running 3s test @ http://127.0.0.1:8080/0.html 6 threads and 300 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.87ms 5.30ms 80.97ms 99.53% Req/Sec 14.73k 1.60k 16.33k 94.67% 248455 requests in 3.08s, 55.68MB read Socket errors: connect 0, read 248448, write 0, timeout 0 Requests/sec: 80783.03 Transfer/sec: 18.10MB ./wrk -c300 -d3 -t6 "http://127.0.0.1:8080/100.html" Running 3s test @ http://127.0.0.1:8080/100.html 6 threads and 300 connections Thread Stats Avg Stdev Max +/- Stdev Latency 263.15us 381.82us 16.50ms 99.60% Req/Sec 115.55k 14.38k 154.55k 82.70% 1946700 requests in 3.00s, 655.35MB read Requests/sec: 649367.11 Transfer/sec: 218.61MB weighttp -kn300000 -c300 -t6 "http://127.0.0.1:8080/0.html" progress: 100% done finished in 1 sec, 709 millisec and 252 microsec, 175515 req/s, 20159 kbyte/s requests: 300000 total, 300000 started, 300000 done, 150147 succeeded, 149853 failed, 0 errored status codes: 150147 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 35284545 bytes total, 35284545 bytes http, 0 bytes data weighttp -kn300000 -c300 -t6 "http://127.0.0.1:8080/100.html" progress: 100% done finished in 0 sec, 417 millisec and 935 microsec, 717813 req/s, 247449 kbyte/s requests: 300000 total, 300000 started, 300000 done, 300000 succeeded, 0 failed, 0 errored status codes: 300000 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 105900000 bytes total, 75900000 bytes http, 30000000 bytes data 

Nginx的

 ./wrk -c300 -d3 -t6 "http://127.0.0.1:8080/100.html" Running 3s test @ http://127.0.0.1:8080/100.html 6 threads and 300 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.54ms 1.16ms 11.67ms 72.91% Req/Sec 34.47k 6.02k 56.31k 70.65% 539743 requests in 3.00s, 180.42MB read Requests/sec: 179939.40 Transfer/sec: 60.15MB ./wrk -c300 -d3 -t6 "http://127.0.0.1:8080/0.html" Running 3s test @ http://127.0.0.1:8080/0.html 6 threads and 300 connections Thread Stats Avg Stdev Max +/- Stdev Latency 1.44ms 1.15ms 9.37ms 75.93% Req/Sec 38.16k 8.57k 62.20k 69.98% 596070 requests in 3.00s, 140.69MB read Requests/sec: 198800.93 Transfer/sec: 46.92MB weighttp -kn300000 -c300 -t6 "http://127.0.0.1:8080/0.html" progress: 100% done finished in 1 sec, 630 millisec and 19 microsec, 184046 req/s, 44484 kbyte/s requests: 300000 total, 300000 started, 300000 done, 300000 succeeded, 0 failed, 0 errored status codes: 300000 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 74250375 bytes total, 74250375 bytes http, 0 bytes data weighttp -kn300000 -c300 -t6 "http://127.0.0.1:8080/100.html" progress: 100% done finished in 1 sec, 506 millisec and 968 microsec, 199075 req/s, 68140 kbyte/s requests: 300000 total, 300000 started, 300000 done, 300000 succeeded, 0 failed, 0 errored status codes: 300000 2xx, 0 3xx, 0 4xx, 0 5xx traffic: 105150400 bytes total, 75150400 bytes http, 30000000 bytes data 

Nginx配置文件试图匹配G-WAN的行为

 # ./configure --without-http_charset_module --without-http_ssi_module # --without-http_userid_module --without-http_rewrite_module # --without-http_limit_zone_module --without-http_limit_req_module user www-data; worker_processes 6; worker_rlimit_nofile 500000; pid /var/run/nginx.pid; events { # tried other values up to 100000 without better results worker_connections 4096; # multi_accept on; seems to be slower multi_accept off; use epoll; } http { charset utf-8; # HTTP "Content-Type:" header sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 10; keepalive_requests 10; # 1000+ slows-down nginx enormously... types_hash_max_size 2048; include /usr/local/nginx/conf/mime.types; default_type application/octet-stream; gzip off; # adjust for your tests gzip_min_length 500; gzip_vary on; # HTTP "Vary: Accept-Encoding" header gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; # cache metadata (file time, size, existence, etc) to prevent syscalls # this does not cache file contents. It should helps in benchmarks where # a limited number of files is accessed more often than others (this is # our case as we serve one single file fetched repeatedly) # THIS IS ACTUALY SLOWING-DOWN THE TEST... # # open_file_cache max=1000 inactive=20s; # open_file_cache_errors on; # open_file_cache_min_uses 2; # open_file_cache_valid 300s; server { listen 127.0.0.1:8080; access_log off; # only log critical errors #error_log /usr/local/nginx/logs/error.log crit; error_log /dev/null crit; location / { root /usr/local/nginx/html; index index.html; } location = /nop.gif { empty_gif; } location /imgs { autoindex on; } } } 

欢迎评论 – 特别是Nginx的专家 – 根据这个完整的文档测试进行讨论。