nginx - Подсистема балансировки нагрузки - Значительная задержка, когда восходящий узел офлайн/вниз

Выполнение nginx 1.0.15 на CentOS 6.5. У меня есть три вышестоящих сервера, и все хорошо работает, однако когда я моделирую отключение электричества и удаляю один из вышестоящих серверов, я замечаю значительную задержку в ответ времена (дополнительные 5-7 секунд). Второе я возвращаю побежденный сервер онлайн, задержка, исчезает. Кроме того, другая странная вещь, которую я заметил, если я просто останавливаю httpd сервис на моделируемый сервер отключения электричества, время отклика, нормальна, задержка только происходит, если сервер полностью снижается.

Вот мой conf:

upstream prod_example_com {

    server app-a-1:51000;

    server app-a-2:51000;

    server app-a-3:51000;

}


server {

    # link:  http://wiki.nginx.org/MailCoreModule#server_name
    server_name example.com www.example.com *.example.com;

    #-----
    # Upstream logic
    #-----


    set $upstream_type prod_example_com;


    #-----

    include include.d/common.conf;

    # Configure logging
    access_log  /var/log/nginx/example/access/access.log access;
    error_log   /var/log/nginx/example/error.log error;

    location / {

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_pass
        proxy_pass  http://$upstream_type$request_uri;

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_set_header
        proxy_set_header    Host    $host;
        proxy_set_header    X-Real-IP   $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_pass
        proxy_pass  http://$upstream_type$request_uri;

        # link: http://wiki.nginx.org/HttpProxyModule#proxy_set_header
        proxy_set_header    Host    $host;
        proxy_set_header    X-Real-IP   $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;

        proxy_hide_header expires;
        proxy_hide_header Cache-Control

         # Even tho this reads like the older syntax, it is handled internally by nginx to set max age to now + 1 year
         expires max;

        # Allow intermediary caches the ability to cache the asset
        add_header Cache-Control "public";
    }
}

Я попробовал предложения на подобных сообщениях как это. И по-видимому моя версия nginx слишком стара для поддержки health_checks, как обрисовано в общих чертах в nginx документах. Я также попытался явно установить max_fails=2 и fail_timeout=120 на app-a-3 восходящее определение, но ни один из них, кажется, не избегает задержки дополнительных 5-7 секунд для каждого запроса если app-a-3 в режиме офлайн.

- Обновление-

На запрос вот вывод для единственного запроса когда app-a-3 полностью снижается. Единственной вещью, которую я видел необычный, являются 3 вторых задержки между начальным событием и последующим событием.

- Обновление № 2--

Похож несколько лет назад на Nginx, решенный для создания Nginx Плюс, который добавляет активные проверки состояния, но для ежегодного контракта на поддержку. На основе некоторых статей я читал, Nginx устал от создания компаний миллионы и получение ничего в ответ.

Как упомянуто в комментариях мы загружаем и не имеем $$ для броска в контракт за 1 350$. Я действительно находил этот repo, который обеспечивает функциональность. Удивление, если у кого-либо есть опыт с ним? Стабильный? Производительный?

Худший вариант развития событий, к которому я буду просто иметь, стиснул зубы, и заплатите дополнительные $20 / месяц для Linode "Стабилизатор Узла", который я вполне уверен, базируется прочь Nginx Плюс. Единственная проблема нет никакого управления конфигурацией кроме нескольких универсальных опций, таким образом, никакой способ поддерживать несколько vhost файлов через один стабилизатор и все узлы не должен быть в том же центре обработки данных.

- Обновление № 3--

Вот некоторые результаты осады. Кажется, что второй узел неправильно конфигурируется, поскольку это только может обработать приблизительно 75% запросов, которые обрабатывают первые и третьи узлы. Также я думал это нечетный, что, когда я вывел второй узел из эксплуатации, производительность была так же плоха, как будто я взял третье (лучше работающий) узел офлайн. Логика продиктовала бы что, если бы я удалил слабое звено (второй узел), что я получил бы лучшую производительность, потому что оставление двумя узлами работает лучше, чем слабое звено, индивидуально.

Короче говоря:

node 1, 2, 3 + my nginx = 2037 requests

node 1, 2 + my nginx  = 733 requests

node 1, 3 + my nginx = 639 requests (huh? these two perform better individually so together should be somewhere around ~1500 requests, based on 2000 requests when all nodes are up)

node 1, 3 + Linode Load Balancer = 790 requests

node 1, 2, 3 + Linode Load Balancer = 1,988 requests