Презентация Владимира Храмцова к докладу про оптимизацию двух маленьких PHP проектов. Основыне тезисы: что происходит, когда увеличивается нагрузка, какие возникают проблемы и способы их решения.

1. Разработка на коленке
История оптимизации двух
маленьких проектов

2. А давайте напишем маленький
скрипт
• Пользователю могут выдаваться очки
• Очки можно поменять на бонус
• Возможность посмотреть баланс
• Нет баланса – нет учетки
• Ответы реализованы в виде http codes
(вроде как REST)

3. LAMP
• PHP
• Apache (mod_php, mod_rewrite)
• MySQL (куда же без него)

4. Выгрузились,
запустились,
всё работает,
клиенты ходят,
данные передаются

5. Первая проблема
• Возрастает количество
клиентов и MySQL
начинает потреблять
всё больше
процессорных ресурсов,
хотя slow query log
пустой.
• Проблема в частых
запросах к маленькой
табличке. Запросы
выполняются быстро
(менее 1 секунды), но
нагружается процессор.

6. Но ненадолго

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. Второй проект
• Сеть для показа рекламы
• Нужно было написать не маленький
скрипт, а мини систему управления
контентом.
• Клиенты делают запросы и тянут
рекламу с сервера.

15. Опять же Lamp
• PHP
• Apache
• MySQL

16. Опять же всё написано,
выгружено и вроде даже
стабильно работает, статистика
пишется и все происходит в
режиме реального времени

17. Первые проблемы
• Подсчет статистики
при показе списка
• Кэширование с
пересчетом раз в
полчаса

18. Появление новых возможностей
• Новые типы рекламы по запросу
• Начинаем собирать информацию о
пользователях ( взаимодействие с
приложениями - клиентами )
• Добавление рассылок push notifications
• Деление пользователей на группы
• Возможность фокусирования всех
типов реклам на отдельного
пользователя.

19. И вдруг одно из мобильных
приложений выводят в top и
буквально сразу же начинаются
проблемы с
производительностью серверной
части

20. Результаты вывода в top
• Много установленных приложений –
много запросов к системе (К.О. или таки
уже майор?)
• Приложения-будильники стартуют в
одной часовой зоне практически
одновременно (разбежка часов очень
небольшая)
• Apache забивается запросами статики

21. Что применялось
• Nginx
• Memcached
• Изменения в исходном коде
• APC

22. Nginx
• Отдача статики для всех проектов на
данном сервере
• Обратное проксирование

23. Memcached
• Компромисс между мгновенным
отражением изменений данных и
производительностью системы.
• Кэширование редко изменяющихся
данных

24. Изменения в исходном коде
• Проверка некоторых условий на
актуальность до главного запроса
• Изменение кода для избежания
deadlocks в MySQL.

25. Результаты
• Улучшение производительности, т.к. На
отдачу статики не расходуются ресурсы
apache
• Улучшение ситуации при работе с
медленными клиентами.
• Снижение нагрузки на MySQL.

26. Общие рекомендации

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

28. Для упрощения поддержания
кэша в адекватном состоянии
стоит использовать
предсказуемые ключи,
например для пользователя
userdata_{id}

29. В некоторых случаях можно
отражать изменения с некоторой
задержкой

30. Кэширование не должно
использоваться как костыль для
решения проблем приложения (а
иногда так хочется).

31. В первую очередь кэширование
стоит применять для данных,
которые редко меняются.
MySQL query cache vs
кэширование на стороне
приложения.

32. Как правило, при кэшировании
всегда доступна операция delete.

33. В некоторых случаях имеет
смысл использовать постоянные
соединения (persistent
connections), однако надо
помнить, что некоторые модули
чистят состояние соединения
(mysqli), а некоторые – нет
(PDO).