Сегодня мне хотелось бы затронуть тему оптимизации. Пройтись, так сказать, по основам, чтобы даже новичку было понятно в какую сторону копать. Необходимо, чтобы у вас был доступ к серверу через shell.

Какое программное обеспечение будет затронуто:

• apache
• nginx
• mysql
• lighttpd
• php
• memcached
• CentOS

– Статика-динамика

Для начала давайте разберемся с web-серверами. Разделим все дело на так называемые front-end и back-end или в просторечье на статику-динамику. Статику (CSS, картинки, JS) у нас будет отдавать какой-нибудь легкий и быстрый сервер, например nginx или lighttpd. А вот динамикой (php) займется привычный большинству Apache. Либо же это может быть Apache-Tomkat(если используется Java).

Преимущества подобной схемы можно понять на небольшом примере. Представьте себе, что к вашему web серверу apache необходимо обслужить порядка 1000 запросов одновременно, причем многие из этих клиентов подключены к медленным каналам связи. В случае использования apache мы получим 1000 процессов httpd на каждый из которых будет выделена оперативная память, и эта память не освободится до тех пор, пока клиент не получит запрошенный контент (в идеальном варианте конечно).

В случае схемы с применением front end/back end сервера получим значительную экономию системных ресурсов за счет того, что после того как пришел запрос клиента, nginx передает запрос apache и быстро получает ответ. В итоге apache после того как отдал ответ nginx освобождает память, далее с клиентом взаимодействует web сервер nginx, который как раз и написан для раздачи статического контента, большому количеству клиентов, при незначительном потреблении системных ресурсов.

– Нагрузка на сервер

Нагрузку на сервер можно определять командой top (вводим в командную строку). Данная команда выводит на экран нагрузку сервера в режиме реального времени. Загрузка каждого из процессоров выводится в виде десятичного числа (Например, 0.94 или 15.3).

На экран будет выведено, что-нибудь подобное этому:

top – 20:55:26 up 50 days, 9:50, 3 users, load average: 0.94, 0.76, 1.26
Tasks: 69 total, 1 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.9% us, 0.2% sy, 0.0% ni, 76.6% id, 22.4% wa, 0.0% hi, 0.0% si
Mem: 1034692k total, 996636k used, 38056k free, 12484k buffers
Swap: 3068372k total, 176k used, 3068196k free, 933656k cached

Для того, чтобы посмотреть список процессов вводим команду ps.

– Нагрузка на MySQL

Обычно основная нагрузка ложится именно на сервер базы данных. Поэтому этот пункт стоит отметить особо. И уделить внимание оптимизации mysql-сервера тоже нужно особое. Подробнее о том, как подключиться к mysql через командную строку. Подробнее по оптимизации самого mysql можно почитать на этом блоге.

Зайдем через консоль в рабочую базу данных и пишем:
show full processlist;
либо
show processlist;

Данный запрос покажет какие потоки запущены в настоящий момент.

Эта команда очень полезна, если выдается сообщение об ошибке ‘too many connections’ (слишком много соединений) и необходимо выяснить, что происходит. MySQL резервирует одно дополнительное соединение для клиента с привилегией SUPER, чтобы у вас всегда была возможность войти в систему и произвести проверку (предполагается, что вы не станете раздавать эту привилегию всем своим пользователям).

* не забывайте ставить точку с запятой в конце каждой команды!

Также стоить обратить внимание на параметр конфигурации
-log-slow-queries
Если используется этот параметр, в лог-журнал будут записываться все медленные запросы. Вам останется только сделать выводы и найти пути решения.

Теперь разберемся с запросами. Находим через show processlist; или -log-slow-queries «грузящие» процессы и приступаем к оптимизации. Вариантов несколько:

1. упрощение запросов;
2. кэширование данных в оперативную память (например, memcached).

Еще один немаловажный момент – частые вставки (INSERT). При существенных нагрузках запросы типа INSERT могут не успевать обрабатываться и они будут попросту сбрасываться. Как вариант можно использовать INSERT DELAYED (запрос будует ставится в очередь на выполнение и когда ресурсы освободятся – запрос будет выполнен). Однако стоит отметить, что INSERT DELAYED не поддерживается InnoDB. Как правило INSERT DELAYED стоит использовать в таблицах, где хранится статистическая информация и запросы на INSERT превышают запросы на SELECT.

– Сессии

Сессии являются файловым хранилищем, поэтому обращение к ним следует минимизировать. И по возможности хранить данные в cookie. Только не забывайте о мерах безопасности, т.к. пользовательские куки легко подделать. Как вариант хранить данные сессий в том же memcached.

p.s. здесь не были затронуты такие темы, как шардинг, партиционирование, репликация. Каждая из них заслуживает отдельного внимания и проработки.

Может быть Вам это интересно?

• Установка nginx,eaccelerator и обновление php,mysql,apache на CentOS
• В продолжение о серверах
• CentOS
• Хранимые процедуры в MySQL
• Конвертер SQLite to Mysql