71  /  97

Обеспечение производительности

Просмотров: 19113
Дата последнего изменения: 17.01.2024
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
1
2
3
4
5

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

  Проблемы на клиентской стороне

Тестирование локально, проведённое при разработке проекта, - это хорошо, но далеко не всё. Нужны замеры в реальных условиях. Можно собирать статистику: по скорости рендеринга javascript в браузере клиента, DNS резолвингу, TCP соединениям и вообще, всё, что можно собрать внутри браузера клиента. С помощью Pinba эта статистика может выводиться в удобном виде для анализа. Pinba сохраняет данные по онлайн агрегации хитов за последние 15 минут (по умолчанию).

Пример регистрации в pinba браузерной статистики из Navigation Timing API

Все эти данные можно получить средствами js внутри браузера клиента и передать в MySQL хранилище Pinba:

Одним запросом в Pinba можно увидеть у каких клиентов сейчас, в каких подсетках тормозит DNS, тормозит TCP или рендер тормозит и так далее. Разработчик одним взглядом видит то, что видят сейчас видит обобщённый клиент его проекта.

Далее из Pinba можно можно выбрать данные:

Рендер у Клиентов:

select avg(round(timer_value/req_count,3)) from bx24_cps_js_performance_host where tag2_value='domContentLoadedEventStart-responseStart';

Рендер в браузерах:

select substring(tag2_value,1,100) as ua, avg(round(timer_value/req_count,3)) as avg_time,count(*) from bx24_cps_js_performance_jstimer_ua where tag1_value='domContentLoadedEventStart-responseStart' group by ua order by count(*) desc limit 10;

DNS-скорость:

&select tag2_value, avg(round(timer_value/req_count,3)) as avg_ip_time, count(*) from bx24_cps_js_performance_jstimer_ip where tag1_value='domainLookupEnd-domainLookupStart' group by tag2_value order by count(*) desc limit 20; 

Топ коннектов:

mysql> select tag2_value, avg(round(timer_value/req_count,3)) as avg_ip_time from bx24_cps_js_performance_jstimer_ip where tag1_value='connectEnd-connectStart' group by tag2_value order by avg_ip_time desc limit 20; +-----------------+-----------+ |    176.60.226.9 | 7.6150000 | |  119.32.156.237 | 3.9420000 | |   79.133.133.97 | 3.2835000 | | 78.138.133.2 | 2.4352500 | | 195.38.55.178 | 1.9980000 |

Примечание: Аналогично можно мерить отдачу из CDN.

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

Научитесь быстро локализовывать источник проблем, это могут быть:

  • Проблемы провайдера (анализ TCP коннекта, DNS)
  • Проблемы сети: временные «тормоза» (congestion) сети
  • Проблемы клиента: тормозит браузер клиента (играет в WOT в соседнем окне)
  • Проблема в проекте

  Проблемы на серверной стороне

Если на клиентской стороне все в порядке, то реальная проблема на серверной стороне. Тут возможны две группы причин:

  • Медленная отдача статики;
  • Медленная генерация динамического контента.

Диагностика проблем со статикой - самое простое. Возможно:

  • Завис сервер (смотрим логи).
  • Резервное копирование запущено не вовремя.
  • Канал забит до сайта (редкая ситуация). Смотреть логи, графики.
  • Проблемы с машиной: память/диски - объем и нагрузка. Мерять iostat и другими утилитами.
  • Использование local storage, на котором есть еще 50 проектов.

Решение проблем статики

Оптимально - использование CDN. Не, если в силу каких-то причин это неприемлемо, можно вынести статику на отдельный домен, что позволит скачивать статику в несколько потоков. Либо перенести статику на отдельный сервер(ы) с быстрыми дисками.

И обязательный мониторинг, позволяющий ловить проблемы сразу по их возникновению.

Очень редко, но бывает, что статика "пробивается" через двухуровневую конфигурацию на Apache/PHP-FPM, то есть NGNIX вместо того, чтобы отдавать статику, начинает передавать запросы на Apache. Возможные причины такого явления - неправильная вёрстка, неправильная настройка NGNIX. Для локализации проблемы можно использовать тесты (apachetop). Также проблему можно увидеть на странице /server-status сервера Apache.

  500-ые ошибки

Эти ошибки берутся из-за back-end'а. Такие ошибки нужно по возможности прятать от клиента. Поэтому сделайте красивую страницу с уведомлением пользователей и разбирайтесь с проблемой: смотрите логи.

  База данных

При проблемах с Базой данных основной инструмент диагностики - логи. Постоянный мониторинг тестами Percona XtraDB, например:

Данные выводятся в виде общей статистики, сразу видно когда начались проблемы:

При больших объёмах данных рекомендуется познакомиться с CAP, NoSQL, изучить репликацию, посмотрите про Galera.

Сама по себе БД не тормозит. Тормозят запросы, которые задаются разработчиком. Ищите решение в них.

  PHP

Если тормозит PHP, для выявления проблем используйте:

  • Графики Pinba (скорость выполнения страницы, время system time, user time, PHP)
  • php-fpm slow log
  • gdb, strace
  • XHProf
  • Анализ логов приложения, распределения.
  • Полезно измерять не только среднее значение показателя, но и оценивать распределение значений. На гистограмме времени отработки или использования памяти можно увидеть много интересного: например 95% быстрых хитов и 5% очень очень медленных. Не менее полезен анализ распределения по процентилям.

  Материалы по теме

  • Профилирование нагрузки на файловую систему с помощью iostat и gnuplot Статья на habrahabr.ru




2
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии