Hello!
On Sun, Dec 22, 2013 at 01:24:03PM -0500, Helg wrote:
> Ок.
> Тогда прошу пояснить, как правильно все настроить.
> Дано:
> 1. Однопоточный быстрый бэкэнд, который можно запустить в любом количестве
> копий
> 2. Сервер с 12 ядрами (24 потока в режиме гиперттединга)
> 3. Клиент, присылающий
Nike manufactured a big UK Cheap Nike Blazers Sale Online http://www.art-deco-poster-canada.com/nike-free-run-men-c-44.html>Cheap
Nike free run menWith Free Shipping play with Michael jordan. Previous
to Nike blazers arrived within the world, Nike had been uncommon for just a
gambler to obtain his
On Sun, Dec 22, 2013 at 05:25:59PM -0500, Helg wrote:
> > А unix-сокеты уже пробовали использовать и всё равно настолько тяжело
> > создавать соединения?
>
> клиент создает минимум 9000 QPS. А может и больше.
> Бэкэнд вполне такое тянуть может, в него не упираемся.
Если у вас в качестве прокладки
> Применение multiwatch позволяет мультиплексировать соединения от nginx
> к бэкэндам.
Прошу прощения. Поторопился с выводами :(
Как только nginx создает больше соединений, чем запущено бэкэндов - все
опять виснет.
Соединения остаются висеть:
tcp0 0 127.0.0.1:3191 127.0.0.1:
> А unix-сокеты уже пробовали использовать и всё равно настолько тяжело
> создавать соединения?
клиент создает минимум 9000 QPS. А может и больше.
Бэкэнд вполне такое тянуть может, в него не упираемся.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245757,245773#msg-245773
__
22.12.2013 22:23, Helg wrote:
>> Запустите, например 24 инстанса вашего демона на разных портах.
>> Всех их пропишите под один upstream. Метод балансировки least_conn,
>> keepalive выключите.
> Да. Но тогда на каждый запрос будет создаваться новое соединение. Этого и
> хочется избежать.
А unix-соке
Тихо сам с собой я веду беседу...
Нашел решение проблемы. Не скажу, что оно мне нравится, но оно проблему
решает. Правда, я думал, что nginx сам разбирается с соединениями до
бэкэндов. Ну нет - значит нет.
spawn-fcgi -p 12000 -n -- /usr/bin/multiwatch -f 1 ./fcgitest
Применение multiwatch позвол
> То есть если nginx решает задействовать два воркера и так совпадает,
> что они оба пытаются установить соединение с бэкэндом, то все виснет,
> потому что один из воркеров не может подключиться?
Проверил сейчас.
- 1 воркер и 1 бэкэнд - все ок на любом количестве запросов.
- 2 воркера и 1 бэкэнд
> У вас бекенд способен обрабатывать не более одного соединения.
> Если вдруг соединений пытается образоваться больше одного (e.g.,
> запросы
> начинает обрабатывать другой рабочий процесс) - всё ломается.
То есть если nginx решает задействовать два воркера и так совпадает, что они
оба пытаются
> Запустите, например 24 инстанса вашего демона на разных портах.
> Всех их пропишите под один upstream. Метод балансировки least_conn,
> keepalive выключите.
Да. Но тогда на каждый запрос будет создаваться новое соединение. Этого и
хочется избежать.
> Тогда ваш сервис сможет обслуживать до 24 од
Здравствуйте.
Запустите, например 24 инстанса вашего демона на разных портах.
Всех их пропишите под один upstream. Метод балансировки least_conn,
keepalive выключите.
Тогда ваш сервис сможет обслуживать до 24 одновременных соединений,
остальные будут ждать.
А еще лучше запилить хоть какое-то мул
Ок.
Тогда прошу пояснить, как правильно все настроить.
Дано:
1. Однопоточный быстрый бэкэнд, который можно запустить в любом количестве
копий
2. Сервер с 12 ядрами (24 потока в режиме гиперттединга)
3. Клиент, присылающий запросы в 16 потоков
То есть, нужно:
- выбрать правильное число воркеров =
Hello!
On Sat, Dec 21, 2013 at 03:59:45PM -0500, Helg wrote:
> У меня не работает upstream keepalive в связке с fastcgi-c бэкэндом.
[...]
> Вроде тут виснуть нечему. Но виснет.
> Подскажите, может стакливались с таким? Как чинить. И как
> продиагностировать, в чем именно проб
Здравствуйте.
У меня не работает upstream keepalive в связке с fastcgi-c бэкэндом.
libfcgi - 2.4
nginx - 1.4.1, 1.5.8
Ubuntu 13.10 x64
Конфиг ngnix`а сделан по документации:
upstream test {
server 127.0.0.1:12000;
keepalive 32;
}
location / {
access_log off;
error_log /var
14 matches
Mail list logo
