ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Производительность. nginx to nginx или nginx to fpm



для не локальных соединений лучше использовать nginx <-> nginx (т.е. http - 
http) 
это много надёжней, стабильней и пр. 

On 22.08.2010, at 18:47, Alexandr Sergeyev wrote:

> Антон,
> 
> Если вам реально нужно позаботиться о производительности - ответьте сначала 
> себе на все вопросы:
> 
> Сколько у вас воркеров, сколько соединений ваш frm может держать, сколько 
> соединений он может нагрузить на mysql, какой у вас "план Б" 
> (redundancy/failover, что случается при отказах какого-то из компонентов 
> системы) итп. Как вы защищаете бэкэнд от прямого доступа клиентов если это 
> вам нужно. Нужно ли вам чтоб бэкэнд работал бы с фронтэндом через keep-alive 
> соединение (опять же тогда постоянно занятые сокеты php вам могут неподойти)
> 
> На мой взгляд nginx фронтэнды на два-три апача c php стоит тоже рассматривать 
> как одну из альтернатив.
> 
> Сделайте тесты наконец. Httperf на всё даст хорошие ответы, соберите для него 
> разумный лог сессий, напрягите ваши сервера
> 1) сколько соединений один бэкэнд выдержит без ошибок
> 2) сколько соединений один бэкэнд выдержит если его прикрыть middleware 
> (локальный nginx или апач php)
> 3) сколько соединений один бэкэнд ответит через удалённый прокси 
> 4) сколько соединений один бэкэнд прикрытый локальным nginx/apache ответит 
> через удалённый прокси 
> 5) опционально поэкспериментируйте с прокси настройками и самими прокси 
> (squid/varnish/apache traffic server) и с middleware (haproxy итп... тут на 
> самом деле лучших результатов чем тонко настроенный nginx вряд ли можно 
> добиться, скорее нужно настраивать OS)
> 6) опционально протестируйте крах компонентов системы начиная от дисков и 
> mysql до удалённого прокси (не забыв возможность потери канала между 
> удалённым прокси и главными серверами).
> 
> 
> Удачи.
> 
> Саша Сергеев.
> abc@xxxxxxxxxxxxxxxx
> 
> 
> 
> ----- Original Message -----
> From: "SaveFrom.net" <savefrom@xxxxxxxxx>
> To: "nginx-ru" <nginx-ru@xxxxxxxxx>
> Sent: Saturday, August 21, 2010 3:45:38 PM
> Subject: Производительность. nginx to nginx или nginx to fpm
> 
> Здравствуйте, уважаемые читатели подписки.
> Воркэраунд следующий: фронтэнд и географически удаленный бэкэнд на php
> + БД(redis). С бэкэнда запрашивается небольшое кол-во информации
> (буквально одни заголовки), однако запросов довольно много.
> 
> Сейчас запросы идут по следующей схеме:
> nginx -> nginx + php-fpm
> 
> как считаете, будет ли оправдана ли смена схемы работы на
> nginx -> php-fpm (на удаленной машине)
> 
> т.е. есть с фронтэнда напрямую обращаться к php-fpm, запущенному на бэкэнде.
> 
> Как считаете, имеет ли это смысл с точки зрения производительности?
> 
> С уважением, Антон
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://nginx.org/mailman/listinfo/nginx-ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.