Большинство из нас конечно же слышало о правиле 80/20, известное так же как «Принцип Парето»: 80% усилий дают 20% результата.

Так как нами было произведено много оптимизаций производительности сайтов на Drupal, мы заметили некоторое время назад, что это правило будет верно и для оптимизации: там будет несколько основных причин, на которые приходится основная часть симптомов, будь то  медлительность, неспособность разобраться во многих одновременно работающих пользователей, или неудовлетворительное использование ресурсов сервера. 

Что было

Один из таких случаев выявлен у клиента, с которым мы работаем. Они получают более 415000 просмотров страниц в день и 100.000 посещений (отслеживается с помощью Google Analytics). Они не используют другие инструменты для измерения показателей ресурсов сервера и анализа логов. 

Таким образом, в дополнение к нашим оценкам производительности Drupal, настройке и оптимизация обслуживания, мы рекомендовали, что мы также сделаем оптимизацию их Drupal-сервера, соответствующие инсталляции, конфигурации и настройки на нем. Они согласились, и мы приступили к настройке нового сервера с оптимизированным стеком в той же хостинговой компании, в которой они обслуживались. 

Повышение производительности

После того как мы установили наши рекомендуемый набор программных средств, мы обнаружили, что Awstats говорит, что страница просматривается 950000 раз в день. Ранее мы не видели таких высоких отклонений по сравнению с Google Analytics. Обычно, погрешность составляет около 20% (больше у Awstats по с равнению с Google Analytics). 

Мы сделали обычные настройки, которые мы обычно делаем для клиентов, включая настройку memcached для Drupal, PHP работает как fcgid с Apache и установка кэш PHP-код OP / ускорителя. 

Эти решения помогли, и мы смогли получить более высокую стабильность и производительность на одном сервере. 

Разница производительности 

Но все еще оставались некоторые сложности, заметные при использовании ресурсов сервера, таких как скачки средней загрузки при вводе/выводе данных. 

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

Запрос API «Текущий пользователь» вид которого представлен ниже, занимал на выполнение от 6 до 14 секунд:

SELECT node.nid AS nid,
node.title AS node_title,
votingapi_vote_node_vote_curuser.value_type AS votingapi_vote_node_vote_curuser_value_type,
votingapi_vote_node_vote_curuser.value AS votingapi_vote_node_vote_curuser_value,
votingapi_vote_node_vote_curuser.timestamp AS votingapi_vote_node_vote_curuser_timestamp
FROM node node
LEFT JOIN votingapi_vote votingapi_vote_node_vote_curuser
ON node.nid = votingapi_vote_node_vote_curuser.content_id
AND (votingapi_vote_node_vote_curuser.content_type = ‘node’
AND votingapi_vote_node_vote_curuser.tag = ‘vote’
AND votingapi_vote_node_vote_curuser.uid = ‘0’)
WHERE (node.status <> 0)
AND (votingapi_vote_node_vote_curuser.value IS NOT NULL)
ORDER BY votingapi_vote_node_vote_curuser_timestamp DESC
LIMIT 231300, 50;

Объясняется тем, что он выводил данные «с использованием временных файлов», поэтому неудивительно, что выполнение запроса происходило крайне медленно.

Как только мы отключили этот вид, все стало работать гораздо стабильнее.

Существенное улучшение

Посмотрите в 5 часов вечера в следующие графы, и сравнить до и после.

MySQL число медленных запросов резко падает.

I / O графа стат показывает едва ли деятельность после изменения / Dev /TMP  (корень диска, который имеет / TMP каталог, который MySQL использует для временных таблиц). 

Средняя нагрузка падает visibily как результат.

И PHP CGI процессы показывают гораздо меньше дисперсии. 

Заключение

Во многих случаях снижение производительности — это эффект «низко висящих плодов»,  который является примером повышения производительности за счет совершения  относительно небольших усилий.