Плохой шлюз 502 после небольшого нагрузочного теста на fastcgi-mono-сервере через nginx и ServiceStack

Question

Я пытаюсь запустить API веб-сервиса с ServiceStack под nginx и fastcgi-mono-server.

Сервер запускается нормально, и API работает. Я вижу время отклика в браузере через профилировщик ServiceStack, и они работают менее 10 мс.

Но как только я провожу небольшой нагрузочный тест, используя "осаду" (только 500 запросов, используя 10 подключений), я начинаю получать 502 Bad Gateway. И чтобы восстановить, я должен перезапустить fastcgi-mono-сервер.

Сервер nginx в порядке. Fastcgi-mono-сервер - тот, который перестает отвечать после этой небольшой нагрузки.

Я попытался использовать сокеты tcp и unix (я знаю о проблеме с разрешениями для сокета unix, но я уже исправил это).

Вот мои конфигурации:

server {
    listen       80;
    listen       local-api.acme.com:80;
    server_name  local-api.acme.com;

    location / {
        root   /Users/admin/dev/acme/Acme.Api/;
        index index.html index.htm default.aspx Default.aspx;
        fastcgi_index Default.aspx;
        fastcgi_pass unix:/tmp/fastcgi.socket;
        include /usr/local/etc/nginx/fastcgi_params;            
    }
}

Чтобы запустить fastcgi-mono-сервер:

sudo fastcgi-mono-server4 /applications=local-api.acme.com:/:/Users/admin/dev/acme/Acme.Api/ /socket=unix:/tmp/fastcgi.socket /multiplex=True /verbose=True /printlog=True

РЕДАКТИРОВАТЬ: я забыл упомянуть важную деталь: я запускаю это на Mac OS X.

Я также протестировал все возможные конфигурации веб-сервера для Mono: консольное приложение, модули apache mod_mono, nginx fast_cgi и proxy_pass. Все представили одну и ту же проблему сбоя после нескольких запросов под Mono 3.2.3 + Mac OS X.

Я смог протестировать ту же конфигурацию на машине с Linux, и у меня там не было никаких проблем.

Так что, похоже, это проблема Mono/ASP.NET при работе в Mac OS X.

Answer 1

РЕДАКТИРОВАТЬ: я вижу в исходном вопросе, что не было никаких проблем при работе под Linux, однако я столкнулся с трудностями и в Linux, в сценариях "высокой нагрузки" (то есть +50 одновременных запросов), так что это может относиться к OS X как Что ж...

Я углубился в эту проблему и нашел решение для моей установки - я больше не получаю 502 ошибки Bad Gateway при нагрузочном тестировании моего простого приложения hello world. Я протестировал все на Ubuntu 13.10 с новой компиляцией Mono 3.2.3, установленной в /opt/mono.

Когда вы запускаете сервер mono-fastcgi-4 с параметром "/verbose=True /printlog=True", вы увидите следующий вывод:

Root directory: /some/path/you/defined
Parsed unix:/tmp/nginx-1.sockets as URI unix:/tmp/nginx-1.sockets
Listening on file /tmp/nginx-1.sockets with default permissions
Max connections: 1024
Max requests: 1024

Важные строки - "максимальное количество подключений" и "максимальное количество запросов". Это в основном говорит, сколько активных TCP-соединений и запросов сможет обработать моно-fastcgi сервер - в данном случае 1024.

Моя конфигурация NGINX гласила:

worker_processes 4;
events {
    worker_connections  1024;
}

Таким образом, у меня есть 4 рабочих, каждый из которых может иметь 1024 соединения. Таким образом, NGINX с радостью принимает 4096 одновременных подключений, которые затем отправляются в моно-fastcgi (который желает обработать только 1024 conns). Следовательно, mono-fastcgi "защищает себя" и перестает обслуживать запросы. Есть два решения этого:

1. Уменьшите количество запросов, которые NGINX может принять
2. Увеличьте ваш пул fastcgi upstream

1 легко решить, изменив конфигурацию NGINX так:

worker_processes 4; # <-- or 1 here
events {
    worker_connections  256; # <--- if 1 above, then 1024 here
}

Однако это может означать, что вы не сможете максимально использовать ресурсы на своей машине.

Решение для 2. немного сложнее. Во-первых, моно-fastcgi должен запускаться несколько раз. Для этого я создал следующий скрипт (внутри сайта, который должен быть запущен):

function startFastcgi {
    /opt/mono/bin/fastcgi-mono-server4 /loglevels=debug /printlog=true  /multiplex=false /applications=/:`pwd` /socket=$1 &
}
startFastcgi 'unix:/tmp/nginx-0.sockets'
startFastcgi 'unix:/tmp/nginx-1.sockets'
startFastcgi 'unix:/tmp/nginx-2.sockets'
startFastcgi 'unix:/tmp/nginx-3.sockets'

chmod 777 /tmp/nginx-*

Который запускает 4 моно-fastcgi рабочих, каждый из которых может принять 1024 соединения. Тогда NGINX должен быть настроен примерно так:

upstream servercom {
    server unix:/tmp/nginx-0.sockets;
    server unix:/tmp/nginx-1.sockets;
    server unix:/tmp/nginx-2.sockets;
    server unix:/tmp/nginx-3.sockets;
}
server {
    listen 80;
    location / {
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_pass servercom;
        include fastcgi_params;
    }
}

Это настраивает NGINX с пулом из 4 "вышестоящих работников", который он будет использовать в циклическом порядке. Теперь, когда я забиваю свой сервер с помощью Boom в параллелизме 200 в течение 1 минуты, все это хорошо (или вообще нет 502).

Я надеюсь, что вы можете как-то применить это к своему коду и заставить вещи работать:)

PS:

Вы можете скачать мой код Hello World ServiceStack, который я использовал для тестирования здесь.

И вы можете скачать мой полный NGINX.config здесь.

Хотя есть некоторые пути, которые необходимо скорректировать, но это должно послужить хорошей основой.