Как создать быстрый обратный прокси-сервер nginx без кеширования?

Nginx должен быть быстрым - по крайней мере, так говорят.

Я не могу быстро получить nginx. Для тестирования я использую siege в нескольких конфигурациях для моделирования высоких нагрузок. Поэтому я попытался сбалансировать нагрузку на одном сервере (я знаю, что балансировка нагрузки на одном сервере бесполезна, но для тестирования самого балансировщика нагрузки это действительно так). Я установил для справки уже оптимизированный обратный прокси-сервер apache. Я получаю около 80 транзакций в секунду через nginx и около 350 транзакций в секунду при использовании apache, когда я пытаюсь получить тот же - не кешированный - файл с того же внутреннего сервера. Конечно, аппаратное обеспечение и ОС одинаковы (текущий двухъядерный процессор, оперативная память 2G, Ubuntu Server 16.04).

Я пробовал уже менять воркеров, максимальное количество подключений, методы опроса, размеры буфера для проксирования, время ожидания и буферы для клиентов. Я вижу низкую нагрузку на систему, один nginx использует около 1 процента ЦП, и соединения будут ждать где-то от 5 до 6 секунд. Поскольку я хочу измерить производительность обратного прокси, я не хочу ничего кэшировать в этом тесте.

Возникает вопрос: как оптимизировать производительность nginx в качестве обратного прокси без кеширования?

Пример осадной команды: siege -c 100 -b -r 100 -v <loadbalancer>/favicon.ico

Обновить: Немного конфига по запросу. Для обеспечения соответствия вопроса serverfault, пожалуйста, ответьте в основном о полезных параметрах.

user www-data;
worker_processes 2;
pid /run/nginx.pid;
#thread_pool default threads=1500 max_queue=65536;
worker_rlimit_nofile 40000;

events {
    worker_connections 768;
    #multi_accept on;
    #use epoll;
}

http {

    #aio threads=default;
    #proxy_buffers           32 4m;
    #proxy_busy_buffers_size     25m;
    #proxy_buffer_size 512k;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log combined buffer=1k;
    error_log /var/log/nginx/error.log;

    gzip off;
    # gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    upstream kronos-backend {
        server kronos.example.com;
    }

    server {
        listen 80;
        listen [::]:80;

        ssl_certificate     /etc/ssl/certs/snakeoil.crt;
        ssl_certificate_key /etc/ssl/private/snakeoil.key;

        listen 443 ssl;
        listen [::]:443 ssl;

        keepalive_timeout 60;

        root /var/www/vhosts/default;

        index index.html;

        server_name <name>;

        server_tokens off; # Don't show that nginx is bringing out the website.

        location / {
            proxy_set_header Host            <name>;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_pass http://kronos-backend;

            client_body_buffer_size 1M; # Lets keep all client-sent bodies in memory if less than 1 Megabyte. (Default for amd64: 16K)
            client_max_body_size 10M; # Maximum accepted body is 10M (Default is 1M).
        }
    }
}

Я знаю, что этот конфиг не очень чистый. Но он показывает более или менее то, что я уже пробовал. Он получен из конфигурации по умолчанию из пакета nginx в Ubuntu.

Подключение происходит следующим образом:

       +--- apache2 ---+
       |               |
siege -+               +--> some webserver (not of interest)
       |               |
       +--- nginx -----+

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

Конфигурация в apache использует mpm_worker.

ThreadLimit          600
StartServers         4
ServerLimit          11
MinSpareThreads      50
MaxSpareThreads      100
ThreadsPerChild      200
MaxClients           1000
MaxRequestsPerChild  20000

Пример вывода вышеуказанной команды осады:

$ siege -c 100 -b -r 10 <nginx>/wrapper_2_bg.png
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege..      done.

Transactions:                   1000 hits
Availability:                 100.00 %
Elapsed time:                  11.01 secs
Data transferred:               0.12 MB
Response time:                  0.84 secs
Transaction rate:              90.83 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   76.24
Successful transactions:        1000
Failed transactions:               0
Longest transaction:            6.67
Shortest transaction:           0.03


$ siege -c 100 -b -r 10 <apache>/wrapper_2_bg.png
** SIEGE 3.0.5
** Preparing 100 concurrent users for battle.
The server is now under siege..      done.

Transactions:                   1000 hits
Availability:                 100.00 %
Elapsed time:                   3.16 secs
Data transferred:               0.12 MB
Response time:                  0.22 secs
Transaction rate:             316.46 trans/sec
Throughput:                     0.04 MB/sec
Concurrency:                   68.95
Successful transactions:        1000
Failed transactions:               0
Longest transaction:            3.06
Shortest transaction:           0.05