Что важно для любого проекта в интернет? Скорость, надежность и доступность!
Сегодня поделюсь личным опытом по настройке веб-серверов для крупного веб-портала. И-так!
Изначально для работы использовался веб-сервер Apache, умеет делать все, но при этом потребление ресурсов просто колоссальное! (увы, но модульность Apache не настолько хороша и большинство неиспользуемых функций мы видим в виде мертвых использованных мегабайтов оперативной памяти..)
Что можно сделать в данной ситуации? Как вариант — исключить все модули, без которых сможем жить (может не так хорошо, но сможем). Можно пойти дальше и создать связку Frontend и Backend серверов, которая — не отменяет необходимость «тюнинговать» Apache и PHP (он кстати тоже из модулей и тоже кушает много ресурсов!).
Apache мы переведем в разряд Backend сервера, а на роль Frontend сервера возьмем — Nginx! Почему именно Nginx? Работает.. из-за своего скудного функционала — имеет мало модулей и соответственно потребляемые им ресурсы — минимальны 🙂
При построении выше упомянутой связки мы должны руководствоваться следующими правилами:
- Nginx должен пропускать до Apache только нужные запросы (блокировать DDoS атаки, глупые CTRL+F5 в большом количестве от «забавных» пользователей и тп),
- Nginx должен обрабатывать запросы на графические и прочие статические файлы,
- Nginx должен кешировать наиболее часто запрашиваемые данные,
- Nginx должен сжимать (gzip?) данные отдаваемые клиентам (чем быстрее отдали, тем быстрее готовы работать с другим клиентом/запросом),
- Apache должен обрабатывать php скрипты (это главная задача, с которой Nginx не справляется и это даже хорошо — память экономить надо).
Так как Apache обрабатывает php-скрипты — дадим ему spawn-fcgi! (процессы «весят» мало и способны создавать очереди на обработку)
В предыдущих статьях уже рассказывалось про оптимизацию MySQL, PHP, Apache и чуть чуть о FreeBSD. сегодня у нас появился Nginx и необходимо вносить определенные коррективы.
Начнем с Nginx. Что необходимо посмотреть в конфигурационном файле (nginx.conf):
Основной раздел
- worker_processes, количество рабочих процессов, — задайте 2, на первое время точно хватит, а дальше по обстоятельствам
- worker_rlimit_nofile, установите для начала 10000
Events раздел
- worker_connections, количество соединений для одного рабочего процесса, укажите 4096 (BuddyPress кушает до 156 соединений для одной страницы)
http раздел
- sendfile, установите on
- server_tokens, off — спрячьте данные о версии вашего веб-сервера!
- tcp_nopush, установите on
- tcp_nodelay, установите on
- keepalive_request, количество удерживаемых соединений, поставьте для начала 4096 (да и Apache может слегка потеряться — нужно его подождать!)
- keepalive_timeout, время удержания соединений, поставьте 5… (зы: от этого зависит и настройка Apache)
- reset_timedout_connection, установите on, пусть соединения сбрасываются по тайм-ауту! зачем нам в случаи массового обращения к веб-порталу получать утечку памяти?
Продолжение следует..
HTTP, UNIX