Caching g-wan-复制性能声明

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

然后将wrk指向它（使用null文件null.html）

。。性能非常差，实际上似乎存在某种巨大的延迟问题。 在测试期间，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

将WeightPd指向nginx可获得更快的结果：

/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在这个平台上的问题

---

我已经在同一个操作系统上测试了lighttpd、nginx和node.js，结果与预期一致。服务器已经按照通常的方式进行了调整，扩展了临时端口，增加了ulimit，调整了等待时间循环等。

11月7日更新：我们已经修复了G-WAN v4.11.7中的空文件问题，并且G-WAN在这个游戏中的速度（禁用了www缓存）也比Nginx快了一倍

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测试基于G-WAN团队为（Lighttpd服务器团队制作的测试工具）编写的包装，因为ab.c披露的信息是不完整的

其次，测试文件

“null.html”

是。。。一个空文件

我们不会浪费时间来讨论这样一个测试的无关性（您的网站提供了多少空HTML文件？），但这很可能是观察到的“性能差”的原因

创建G-WAN并不是为了提供空文件（我们从未尝试过，也从未要求过这样做）。但我们肯定会添加此功能，以避免此类测试造成的混乱

当您想“检查声明”时，我建议您使用

weightp

（测试中最快的HTTP加载工具）和

100.bin

文件（一个100字节的文件，具有不可压缩的MIME类型：此处不涉及Gzip）

使用非空文件，即使在独立测试中也是如此

到目前为止，我们还不知道

wrk

，但它似乎是由以下公司制造的工具：

“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

就像在您的测试中一样，我们可以看到

wrk

比

weightp

稍慢

我们还可以看到，使用这两种HTTP加载工具，G-WAN比Nginx更快

以下是详细的结果：

---

广域网

---

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专家的评论——根据这个完整记录的测试进行讨论。

我们刚刚修复了G-WAN v4.11.7中的空文件问题，并且G-WAN在这个游戏中的速度也是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

# ./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;
      }
   }
}