Презентация Владимира Храмцова к докладу про оптимизацию двух маленьких PHP проектов. Основыне тезисы: что происходит, когда увеличивается нагрузка, какие возникают проблемы и способы их решения.
2. А давайте напишем маленький
скрипт
• Пользователю могут выдаваться очки
• Очки можно поменять на бонус
• Возможность посмотреть баланс
• Нет баланса – нет учетки
• Ответы реализованы в виде http codes
(вроде как REST)
5. Первая проблема
• Возрастает количество
клиентов и MySQL
начинает потреблять
всё больше
процессорных ресурсов,
хотя slow query log
пустой.
• Проблема в частых
запросах к маленькой
табличке. Запросы
выполняются быстро
(менее 1 секунды), но
нагружается процессор.
7. Выгрузка нового билда
мобильного приложения
• Возникает проблема, когда клиент
начинает обращаться к серверу
несколько раз в секунду вместо одного
раза в 10 минут.
• Клиентов достаточно много, получаем
DDOS атаку.
8. Основные проблемы
• MySQL начинает сбрасывать
соединения.
• Apache начинает проявлять
прибалтийские кооорни.
9. Пути решения
• Увеличение мощности сервера
• Кэширование (memcached).
• Изменяем порядок обработки запросов
на php
10. Увеличение мощности сервера
• Поскольку дело было на Amazon,
увеличение мощности произошло с
помощью одного клика мыши.
11. Кэширование
• Самым частым запросом оказался
запрос на получение учетной записи
клиента. Однако для большинства
запросов учеток не было. Пришлось
кэшировать в memcache все ответы.
• Данные о пользователях сохранялись
по предсказуемым ключам.
• На MySQL Query Cache не
рассчитывали
12. Изменение порядка обработки
запросов на php
• Поскольку apache все равно не
выдерживал потока запросов, было
принято решение заменить его на
nginx+php-fpm (не только потому что его
использовать круто, а apache нет)
• Установка APC
13. Результаты
• Увеличение обслуживаемых rps больше
чем в два раза
• Падение нагрузки на сервер
• 99.9% hits в memcache
• Снижение нагрузки на дисковую
систему
• Нет ситуации с долгим ожиданием
ответа
14. Второй проект
• Сеть для показа рекламы
• Нужно было написать не маленький
скрипт, а мини систему управления
контентом.
• Клиенты делают запросы и тянут
рекламу с сервера.
18. Появление новых возможностей
• Новые типы рекламы по запросу
• Начинаем собирать информацию о
пользователях ( взаимодействие с
приложениями - клиентами )
• Добавление рассылок push notifications
• Деление пользователей на группы
• Возможность фокусирования всех
типов реклам на отдельного
пользователя.
19. И вдруг одно из мобильных
приложений выводят в top и
буквально сразу же начинаются
проблемы с
производительностью серверной
части
20. Результаты вывода в top
• Много установленных приложений –
много запросов к системе (К.О. или таки
уже майор?)
• Приложения-будильники стартуют в
одной часовой зоне практически
одновременно (разбежка часов очень
небольшая)
• Apache забивается запросами статики
23. Memcached
• Компромисс между мгновенным
отражением изменений данных и
производительностью системы.
• Кэширование редко изменяющихся
данных
24. Изменения в исходном коде
• Проверка некоторых условий на
актуальность до главного запроса
• Изменение кода для избежания
deadlocks в MySQL.
25. Результаты
• Улучшение производительности, т.к. На
отдачу статики не расходуются ресурсы
apache
• Улучшение ситуации при работе с
медленными клиентами.
• Снижение нагрузки на MySQL.
27. Отделение часто изменяемых
данных, от тех данных, которые
меняются редко. В частности это
упрощает создание эффективной
системы кэширования. Например
отделение информации о
пользователе от его баланса
28. Для упрощения поддержания
кэша в адекватном состоянии
стоит использовать
предсказуемые ключи,
например для пользователя
userdata_{id}
33. В некоторых случаях имеет
смысл использовать постоянные
соединения (persistent
connections), однако надо
помнить, что некоторые модули
чистят состояние соединения
(mysqli), а некоторые – нет
(PDO).