Если вы владелец приличного сайта - то рано или поздно вам прийдется подкручивать свой выделенный(виртуальный) сервер, на котором разросшийся за несколько лет веб-проект начинает подтормаживать.
Если же вы еще и не профессиональный HighLoad Linux-админ, а, например, разработчик (как я), то в процессе настройки прийдется ловить много-много граблей... ;-)
Хочу немного улучшить состояние вашего лба, рассказав про те шишки, что набивал самостоятельно или с помощью более "администых" друзей. Специальные оптимизации на уровне правок PHP-кода не рассматриваю, это отдельная тема, сейчас - только сервер, консоль и вы, ну может где пару PHP скриптов немного поправить понадобится - буду считать, что свою CMS вы чуть-чуть знаете.
Ниже рассматривается достаточно часто встречаемая комбинация для сайтов: nginx + php (nginx+apache c php немного отличается - вместо fastcgi_xxx будет proxy_xxx).
Да, и считаем, что сейчас все компоненты вашей системы (nginx, php, mysql, memcache) крутятся на одной машине - как оно обычно и бывает на частных ресурсах.
Только для production машин можно отключить проверку Modified time - это абсолютно не подходит, если на сервере идет отладка скриптов - иначе будете ловить постоянные глюки и проблемы - включать только после того как сайт стал стабилен.
Если же вы еще и не профессиональный HighLoad Linux-админ, а, например, разработчик (как я), то в процессе настройки прийдется ловить много-много граблей... ;-)
Хочу немного улучшить состояние вашего лба, рассказав про те шишки, что набивал самостоятельно или с помощью более "администых" друзей. Специальные оптимизации на уровне правок PHP-кода не рассматриваю, это отдельная тема, сейчас - только сервер, консоль и вы, ну может где пару PHP скриптов немного поправить понадобится - буду считать, что свою CMS вы чуть-чуть знаете.
Ниже рассматривается достаточно часто встречаемая комбинация для сайтов: nginx + php (nginx+apache c php немного отличается - вместо fastcgi_xxx будет proxy_xxx).
Да, и считаем, что сейчас все компоненты вашей системы (nginx, php, mysql, memcache) крутятся на одной машине - как оно обычно и бывает на частных ресурсах.
PHP
- Пускаем как fastcgi через сокет
- Pconnect к базе - спорно
- Не забываем акселератор (моя юзает eAccelerator) - хотя тоже есть спорные моменты
eAccelerator
Только для production машин можно отключить проверку Modified time - это абсолютно не подходит, если на сервере идет отладка скриптов - иначе будете ловить постоянные глюки и проблемы - включать только после того как сайт стал стабилен.
eaccelerator.enable="1" eaccelerator.optimizer="1" eaccelerator.check_mtime="0" eaccelerator.shm_only="1"
Временые диски
tmpfs для /tmp и сессий PHP - все это сносится в память, если ее достаточно. В /etc/fstab добавляемtmpfs /tmp tmpfs defaults 0 0 tmpfs /var/lib/php tmpfs size=200M,nr_inodes=1m,nosuid 0 0
MySQL
- Проверяем, включен ли query кэш
- Также используем сокет
- Если в вашей CMS используется таблица сессий - ставим для них тип MEMORY (если нет текстовых полей) - это приведет к сбросу всех залогиненных пользователей при перезагрузке сервера, но добавит немного скорости. Ну или если это неприемлемо - то надеюсь, она уже переведена в InnoDB? ;-)
- Определяем оптимальное количество коннектов - статистика хотя бы за месяц (я юзаю munin). Ставим в 1.5-2 раза больше среднего.
Memcache
Если вся солянка крутится на одной машине - то также используем коннект через сокеты (по умолчанию не используется - стоит ip адрес). В таком варианте работы memcache возможны проблемы с некоторыми средствами мониторинга memcache (которые работают также по IP).
Не забываем в PHP использовать сжатие при работе с MEMCACHE.
Nginx
Ограничиваем число коннектов и запросов, особенно на ресурсоемкие скриптыhttp {
...
limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
limit_zone three $binary_remote_addr 10m;
Включаем кэширование для неавторизованных гостей
http {
...
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=wholepage:50m inactive=15d max_size=5000m;
location ~ .*\.php$ {
limit_conn three 20;
include /etc/nginx/fastcgi.conf;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php-fastcgi/php.socket;
#access_log /var/log/nginx/domain.access.log my_combined;
fastcgi_cache wholepage_guest;
fastcgi_cache_valid 301 302 304 10m;
fastcgi_cache_valid 200 360m;
fastcgi_cache_valid 404 5s;
fastcgi_cache_key "$request_method|$host|$request_uri";
fastcgi_pass_header "Set-Cookie";
fastcgi_ignore_headers "Cache-Control" "Expires";
fastcgi_cache_bypass $cookie_phpbb_session $arg_nocache $arg_PHPSESSID;
fastcgi_no_cache $cookie_phpbb_session $arg_nocache $arg_PHPSESSID;
}
Где phpbb_session - имя куки по которой идет авторизация
Все запросы с ?nocache=1 и PHPSESSID попадают на PHP-бэкенд сразу без кэша не забываем открыть скрипт, по которому идет авторизация (в том числе и всякие капчи - их можно переписать на ?nocache=1) - тут возможно прийдется немного поковыряться и в коде CMS тоже.
location /register.php {
limit_conn three 20;
include /etc/nginx/fastcgi.conf;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php-fastcgi/php.socket;
}
Nginx - общие рекомендации
Очень нежелательно использовать location с регекспами - только простые префиксы видаlocation /mymodule {}
Если от регекспов никак не избавится - то лучше их обрамлять простым location (Причина - сложноуловимые перехлесты в логике парсинга URL - кто за кем будет следовать)
location /mymodule {
location ~ \/mymodule\/(.*)\.php$ {
чего-то
}
}
Отрубаем access лог для картинок
Разумеется - это только основные моменты оптимизации, на самом деле их гораздо больше. А какие трюки для уменьшения нагрузки на сервер знаете вы? Пишите в комментах.
