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

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

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 |

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

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

• Проблемы провайдера (анализ 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