g-wan - воспроизведение заявлений о производительности

ОБНОВЛЕНИЕ 7 ноября: мы исправили проблему с пустым файлом в G-WAN v4.11.7, и теперь G-WAN работает в два раза быстрее (с отключенным кэшем www), чем Nginx, и в этой игре.

Последние выпуски G-WAN работают быстрее, чем Nginx, с небольшими и большими файлами, а кэши G-WAN отключены по умолчанию, чтобы людям было проще сравнивать G-WAN с другими серверами, такими как Nginx.

Nginx имеет несколько функций кэширования (кэш fd для пропуска вызовов stat() и модуль на основе memcached), но оба они обязательно намного медленнее, чем локальный кеш G-WAN.

Отключение кэширования также желательно для некоторых приложений, таких как CDN. Другие приложения, такие как приложения AJAX, значительно выигрывают от возможностей кэширования G-WAN, поэтому кэширование можно повторно включить по желанию, даже для каждого запроса.

Надеюсь, это прояснит этот вопрос.

"воспроизведение заявлений о производительности"

Во-первых, название вводит в заблуждение, поскольку в плохо документированном* тесте выше не используются ни те инструменты, ни ресурсы HTTP, полученные в ходе тестов G-WAN.

[*] где твой nginx.conf файл? каковы заголовки ответов HTTP двух серверов? какой у вас "чистый" 8-ядерный процессор?

Тесты G-WAN основаны на ab.c, оболочке, написанной командой G-WAN для http://redmine.lighttpd.net/projects/weighttp/wiki (тестовый инструмент, созданный командой сервера Lighttpd), поскольку информация, раскрытая ab. c гораздо информативнее.

Во-вторых, проверенный файл "null.html" является... пустым файлом.

Мы не будем тратить время на обсуждение неуместности такого теста (сколько пустых HTML-файлов обслуживает ваш веб-сайт?), но, скорее всего, именно он является причиной наблюдаемого "плохого производительность".

G-WAN не был создан для обслуживания пустых файлов (и мы никогда не пытались и нас никогда не просили сделать это). Но мы обязательно добавим эту функцию, чтобы избежать путаницы, создаваемой таким тестом.

Если вы хотите "проверить утверждения", я рекомендую вам использовать weighttp (самый быстрый инструмент загрузки HTTP в вашем тесте) с файлом 100.bin (100-байтовый файл с несжимаемым типом MIME: no Здесь будет задействован Gzip).

С ненулевым файлом Nginx значительно медленнее, чем G-WAN, даже в независимых тестах.

Пока мы ничего не знали о wrk, но похоже, что это инструмент, созданный Nginx. команда:

"wrk был написан специально для того, чтобы попытаться довести nginx до предела, и в первом раунде тестов скорость была увеличена до 0,5 Мр/с."

ОБНОВЛЕНИЕ (день спустя)

Поскольку вы не удосужились опубликовать больше данных, мы это сделали:

                    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 немного медленнее, чем weighttp.

Мы также видим, что 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, для обсуждения на основе этого полностью документированного теста.