Pull to refresh

Comments 13

Зачем из сырцов пересобирать, можно из experimetal или sid выташить
1)apt-get build-dep nginx && apt-get source nginx
2)правим debian/rules если нужно что-то включить или выключить
3)dpkg-buildpackage -rfakeroot
Получим правильную дебку, которую потом можно развернуть где угодно
В sid — 0.7.14-1 — мало :( В experimental 0.7.14-1 — смысла ставить его моло, тем более что в более свежих версиях исправлены ошибки. Уж если 0.7, то лучше наверное последний или предпоследний релиз.

Ну а про правильную дебку вы конечно правы, хотя в данном случае в принципе обошлось заменой одного файла, что несколько проще.
Неправильно
Правильно — собрать deb пакет и поставить его
Я например — собирал свой пакет

Так нужно делать, чтоб обновление не затерло установленный софт, а в случае «поверх» — оно перезатрет при очередном apt-get апдейте
http-сервером nginx в качестве бэкэнда к apache — наверное все же в качестве фронтенда к апачу вы его поставили.
Никогда не ставьте worker processes больше 2х, лучше worker connections увеличивайте, у меня 2/65535 замечательно работает на высоких нагрузках (2-2.5 тыщи запросов в минуту).

Упс, коммент отправился раньше моих мыслей…

Дефолтные опции компиляции предполагают только httpd, так что строчки
--without-mail_pop3_module
--without-mail_imap_module
--without-mail_smtp_module
можно было не писать…

ну и strips в конце компиляции сделать :)

Еще вызывает опасение данная строка:
set $proxy_uri habrometr.ru:99999$request_uri;

какой смысл вешать интерфейс для proxy_pass на внешний адрес?

P.S. вот здесь есть потрясающий HowTo: ru.wikipedia.org/wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Roxis/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_nginx_%D0%BD%D0%B0_Centos/Fedora/Debian
Ну тогда еще надо юзать proxy_set_header Host $proxy_host;, т.к. юзаются виртуальные хосты. В этом случае можно и локальный интерфейс. Вообще, по личным причинам я пока не скрывал апач внутрях сервера (т.е. апач слушает все интерфейсы). Но в перспективе, конечно это стоит сделать, и тогда уже будет:
proxy_set_header Host $proxy_host;
set $proxy_uri 127.0.0.1:99999$request_uri
Если вы планируете сохранять апач в качестве бекенда и у вас много статики — возможно вам придется по вкусу вот это: 0w.ru/httpd/
Как раз хотел спросить. Все остальное в конфигах, в принципе, и так понятно. Но вот чем руководствоваться при выборе таких параметров, как количество процессов, соединений, размеров буферов памяти и величин таймаутов? Есть какие-то формализируемые критерии выбора этих параметров, или это все шаманство, и танцевать с бубном надо вокруг своего собственного проекта, пробуя его тюнинговать то так, то эдак?
Почему? У Сысоева на сайте написано, есть кое-какие рекоммендации в интернете, есть некоторая информация в рассылке. Тут все элементарно, каждый процесс жрет 10-15 метров оперативки, может обрабатывать до 65535 соединений, если я правильно помню, какой смысл увеличивать кол-во процессов без увеличения кол-ва соединений? Базовые параметры очень просты. Что касается таймаутов — все зависит от вашего бекенда, сетевой он или локальный, что вообще из себя представляет. Буфера — конкретно с какими объемами приходится работать, если у вас файловый сервер, скажем — вы будете разбивать приходящие пакеты на удобного размера чанки и сохранять, чтобы не грузить сразу все в раму. На сайте Сысоева есть много информации.
Процессы лочатся на интенсивном чтении с диска, если много статики раздавать, то лучше увеличивать.
А действительно это так? Моя логика подсказывает, что результат будет одинаков, если раздавать 400 файлов по мегабайту 2мя процессами по 200 или 4мя по 100, здесь бутылочное горлышко — сам диск, а не какие-то ограничения операционной системы. Если не прав — поправьте :)
gzip on;
gzip_proxied any;
Как представитель провайдера с говенно настроенным прокси хочу заметить что не лишне еще прописать
gzip_http_version 1.0;
Sign up to leave a comment.

Articles

Change theme settings