Производительность веб-приложений - инструменты и алгоритмы

Производительность веб-приложений - инструменты и алгоритмы

Сербул Александрруководитель направления контроля качества

интеграции и внедрений 1С-Битрикс

AlexSerbul

1) Поймем предметную область2) Что нас вынуждает беспокоиться?3) Что такое «быстро» и когда «тормозит»4) Как выжить и не проиграть конкурентам

О чем будем говорить

С чего все началось

1) Тим Бернерс-Ли, CERN*2) С 1989 года – WWW/HTTP/HTML3) Первый веб-сервер, первое фото в сети

*ЦЕРН (CERN) — Европейская организация по ядерным исследованиям, крупнейшая в мире лаборатория физики высоких энергий.

Законодатели современной моды

1) Соцсети2) Видео хостинги3) Новостные сайты4) Корпоративные ресурсы,

порталы

Гонка против законов физики

1) Гиганты …2) Часто в «облаках» …3) Теорема CAP и NoSQL4) CDN

Гиганты - изнутри

Архитектура Битрикс24

Elastic Load Balancing

Web 1

Elastic Load Balancing

Dynamic

Web N

…CloudWatch + AutoScaling

Web 1 Web 2 Web N

…CloudWatch + AutoScaling

S3

management, monitoring,

backup

Static

CDN

js, css

DynamicStatic

CDN

js, css

imag

es (c

lient

s)

imag

es (c

lient

s)

local cache

local cache

local cache

local cache

local cache

control cache: memcached

mysqldmysqldmysqld

mysqldmysqldmysqld

master-master replication

master-master replication

master-master replicationmysqldmysqldmysqld

mysqldmysqldmysqld

mysqldmysqldmysqld

mysqldmysqldmysqld






Web 2local

cache

Как выжить, как победить?

Рва

Как победить (или хотя бы выжить)?

1) Понимать, что нужно Клиенту, «вжиться в него»2) Понять принципы создания высоконагруженных, масштабируемых

приложений3) Научиться логировать метрики4) Научиться анализировать их (самое сложное) 5) Запустить процесс с обратной связью6) Свести анализ к маленькому набору индикаторов к ОДНОЙ ЗЕЛЕНОЙ

ЛАМПОЧКЕ

Что видит Клиент

Начнем с «конца». Веб-сервер, кластер, NoSQL, кэши

1) Смотрим на систему глазами Клиента2) Что такое – «тормозит»??3) Производительность JS4) Раздача статики с разных доменов, точек5) CDN6) Latency, TCP/IP7) SSL8) SPDY?

Так бывает часто в client-side

Список известных «безобразий» client-side

1) Много людей… делают сайт2) А следит… один. Иногда это Клиент 3) А сроки спускают сверху иногда…4) Неоптимальные ресурсы: картинки, стили5) Куча файлов6) Google PageSpeed7) Не профилируют8) Профилируют, но т.к. тестов нет – ломают

быстро 9) Алгоритмы – данных стало больше и … все

легло (нанимайте опытных бойцов)

Как мерить client-side производительность

Локальное тестирование – далеко не все. Клиенты – далеко.

1) Cобираем js-meтрики2) Отправляем на сервер в Pinba Storage3) Пишем тесты nagios4) Рисуем в munin

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);


Сбор client-side метрик

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);

Как мерить client-side производительностьАнализ client-side метрикРендер у Клиентов: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 |


1) Аналогично можно мерить отдачу из CDN глазами Клиента2) «Распределенное» тестирование – очень полезно3) Можно фиксировать каждый N хит4) Ставьте тесты на пороги и рисуйте графики5) Клиент ждал больше секунды по причине тормозов веб-проекта

– плохо, заметно!


Научитесь БЫСТРО локализовывать источник ВНЕШНИХ проблем

1) Проблемы провайдера2) Временные «тормоза» (congestion) сети3) Тормозит браузер клиента (играет в WOT в соседнем окне)4) Тормозит ТОЧНО не ваш веб-проект

Скорость локализации – минуты.

Автотесты – nagios/zabbix.

Все пока понятно? Идем дальше.

«Тормоза» на server-side

ТОЧНО ясно, что замедление – на server-side

1) Медленная отдача статики2) Медленная генерация дин. контента

Разбираемся со статикой – обычно это проще:- сервер не «висел»? (логи)- бэкап никто не запускал? - канал не забили? (логи, графики)- память/диски – объем и нагрузка (iostat)- на storage нет еще 50 проектов?- может убрать в CDN?

«Тормоза» на server-side - статика

Сервер баз данных

Сервер статики

Rev. proxy server (Nginx)

Сервер приложений

RDBMS(MySQL)Appl. server (PHP-FPM)

Стат. файлы

Классика:- вынести статику на отдельный домен (|| в браузере)- на отдельный сервер(ы) (быстрее отдача)- в CDN

«Тормоза» на server-side - статика

Подводные камни…

1) Статика «проникает» на apache/php-fpm2) Забиваются тяжелые воркеры3) Все висит

Пишем тест, локализуем: apache /server-status, apachetop

Со статикой - разобрались

1) Статика отдается максимально быстро2) Подкрутили буферы nginx3) Поставили быстрые диски4) Убрали все в CDN5) Создали тесты – покраснеют если «статика» сломается

Осталось самое сложное и интересное.

«Тормоза» на server-side - Приложение

1) Балансировщики:DNSHAProxyAWS ELBNginx…

200 ОК

500 Internal Server Error

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout


Разберитесь в ошибках от upstream!

1) Ошибки приложения – лог2) Очередь забилась и чем: nginx – apache/php-fpm3) Служебная страничка – не шокируйте клиентов


Типовая структура веб-приложения:

1) Авторизовать клиента2) Отдать страницу(ы) из кэша или …3) Сделать выборку из БД4) Обработать данные5) Сформировать верстку и отдать клиенту

Еще есть:XSLT, nginx SSI, js/ajax «фигачит» в БД напрямую…

Страницы быстрые – главная, детальнаяСтраницы «медленные» – выборки с фильтрами, поиск по параметрам

Алгоритмы и V-данных: постраничка, шардинг.

«Тормоза» на server-side – Кэш

1) Кэш – это «наркотик»2) Главное – вовремя соскочить

Кэш:- Файлы- БД- Memcached (кластер)

Гранулированность, граф зависимостейMySQL query cache – «to be or not to be»? ;-)

Выход «есть» – денормализация, NoSQL, async-очереди, «удобные» сценарии, шардинг

«Тормоза» на server-side – БД

1) ACID – ближе к ЛСД2) Что у вас за приложение? CAP «скушает»?

MySQL Replication (+semisync)MySQL – «master-master» A/PGalera/Percona XtraDB Cluster/MariaDB Galera Cluster

«Тормоза» на server-side – PHP

На примере PHP

1) pinba таймеры2) php-fpm slow log3) gdb, strace4) Анализ логов приложения, распределения


gdb –p 123456

(gdb) source /src/php-5.3.19/.gdbinit

(gdb) dump_bt executor_globals.current_execute_data[0x0252d628] stemming() /var/www/html/bitrix/modules/search/tools/stemming.php:231

[0x0252bc78] stemming() /var/www/html/bitrix/modules/search/classes/mysql/search.php:1090

[0x02525ec8] StemIndex() /var/www/html/bitrix/modules/search/classes/general/search.php:1332

[0x025223f8] Index() /var/www/html/bitrix/modules/iblock/classes/general/iblockelement.php:4857

[0x0251b670] UpdateSearch() /var/www/html/bitrix/modules/iblock/classes/general/iblockelement.php:3295

[0x02519c40] Add() /var/www/html/bitrix/modules/crm/classes/general/crm_webdav_helper.php:486

[0x02514010] SaveEmailAttachment() /var/www/html/bitrix/modules/crm/classes/general/crm_email.php:867

[0x065c2030] EmailMessageAdd()

[0x0250fcc8] call_user_func_array() /var/www/html/bitrix/modules/mail/classes/general/mail.php:2477

…


XHProf (github.com/facebook/xhprof)

Почти не создает нагрузку на бою

Можно быстро найти корень проблемы

Полезно автоматически сохранять

трейсы долгих страниц

… и анализировать их с разработчиками

Итоги

1) Алгоритмически страницы НЕ ДОЛЖНЫ тормозить

2) Сброс кэша не должен приводить к коллапсу – денормализация

3) Исследуйте «крайние» случаи

4) А также, мониторьте среднегодовую температуру (+7)

5) Все автоматизируйте и быстро, БЫСТРО, тестами определяйте текущее

состояние веб-системы

6) Принцип ОДНОЙ зеленой лампочки!

7) Только системный подход, обратная связь

Всем удачи!

Производительность – это просто!

Спасибо за внимание! Вопросы?Александр Сербул[email protected] AlexSerbul

mailto:[email protected]

Documents

Производительность веб-приложений - инструменты и алгоритмы