Development on the Knee by Vladimir Khramtsov

418 views
335 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
418
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Development on the Knee by Vladimir Khramtsov

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

×