Просмотров: 19113
Дата последнего изменения: 17.01.2024
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
4
5
Обеспечение производительности проекта в период его эксплуатации требует постоянного внимания. Проблемы могут возникать разные, но в любом случае их можно отнести к проблемам на клиентской или серверной стороне.
Проблемы на клиентской стороне
Тестирование локально, проведённое при разработке проекта, - это хорошо, но далеко не всё. Нужны замеры в реальных условиях. Можно собирать статистику: по скорости рендеринга javascript в браузере клиента, DNS резолвингу, TCP соединениям и вообще, всё, что можно собрать внутри браузера клиента. С помощью Pinba эта статистика может выводиться в удобном виде для анализа. Pinba сохраняет данные по онлайн агрегации хитов за последние 15 минут (по умолчанию).
Пример регистрации в pinba браузерной статистики из Navigation Timing API
|
pinba_timer_add(
array(
'jstimer'=>'responseEnd-responseStart',
'jshost'=>$jshost,
'jsip'=>$_SERVER["REMOTE_ADDR"],
'jsua'=>$_SERVER["HTTP_USER_AGENT"],
),
(intval($_REQUEST["responseEnd"]) - intval($_REQUEST["responseStart"]))/1000
);
pinba_hostname_set( strval(substr($_REQUEST["host"],0,128)) );
pinba_script_name_set( strval(substr($script,0,128)) );
pinba_request_time_set($timef);
|
Все эти данные можно получить средствами 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% очень очень медленных. Не менее полезен анализ распределения по процентилям.