performance engineering stories from #fdminicon saransk

Несколько историй из жизниPerformance Engineer'а

Александр Чистяков, главный инженер Git in Sky,

2014

Как я съел кусок мыла

Александр Чистяков, главный инженер Git in Sky,

2014

Давайте познакомимся

§ Меня зовут Саша§ Я работаю главным инженером в компании Git in Sky§ Мы занимаемся эксплуатацией веб-проектов,

помощью в разработке веб-проектов, собственно разработкой веб-проектов и автоматизацией веб-проектов

§ Во всем этом приходится участвовать мне

Несколько историй из жизни Performance Engineer'а. 2014

А в чем участвуете вы?

§ Веб-разработка?§ Эксплуатация веб-сайтов?§ Поддержка проекта, написанного непонятно кем?§ Борьба с хабраэффектом?§ Принятие решений об аренде/покупке серверов?§ Еще пока не определились, всё такое вкусное?


О чем пойдет речь?

§ Кто такие performance engineers и зачем они нужны§ Как справиться с хабраэффектом§ Сколько серверов нужно, чтобы вкрутить одну

лампочку§ Что лучше: MySQL или MongoDB? PHP, Perl или

Ruby?§ Однажды у моей подруги с ее парнем...


Кто такой performance engineer?

§ Это человек, который делает performance engineering

§ http://en.wikipedia.org/wiki/Performance_engineering § ^ многа букв§ Человек, который знает, как все устроено внутри не

в терминах бизнес-логики приложения


http://en.wikipedia.org/wiki/Performance_engineering

Как бороться с хабраэффектом

§ Я испытываю хабраэффект почти каждый раз, когда открываю статью на Хабре

§ Способы борьбы:§ Не верьте в магию§ Не читайте статьи на Хабре

§ Знание — сила

§ (на самом деле, сила это масса на ускорение)


Структурная схема типичного веб-проекта


Проблемы типичного веб-проекта

§ Непосредственно вытекают из его структуры§ Подразделяются на:

§ ВНЕЗАПНО ничего не работает§ Всё тормозит!§ Мы арендовали c3.xlarge, а оно все равно

тормозит!§ Данные куда-то пропали


Переходим к практике

§ Краткое содержание следующих серий:§ Описание проблемы, происшедшей у моей

подруги с ее парнем

§ Описание пути решения проблемы§ Несколько слов о том, чем именно

руководствовались при решении проблемы, и почему всё удалось (или не удалось)


Случай на производстве №1 (типичный)

§ Сайт-новостник, написанный с использованием UMI.CMS древней версии

§ Проблема: медленно работает админка, время от времени начинает медленно работать всё

§ “Медленно” - страница генерируется десятки секунд


Решение №1 (типичнее некуда)

§ Включить MySQL slow queries log§ На всякий случай добавить в код вызовы

профайлинга (подойдет что угодно — например, записывать скорость генерации страницы в лог, в базу данных, в PINBA, в Graphite или еще куда-то)

§ Убедиться, что проблема в запросах к БД§ Найти долгий запрос и посмотреть его query plan


Почему (не) работает (тоже типично)

§ Запрос сгенерирован ORM и делает фиг знает что§ На самом деле, никто не знает, что именно он

делает, но он джойнит две огромных таблицы, накладывает условия и сортирует результат

§ Индексы не работают, да и не могут§ Такие сортировки — хуже всего для СУБД§ Разработчики не знают, как быть


Альтернативная история

§ Можно хакнуть ORM и заменять “плохой” запрос на “хороший” (резалтсеты должны совпадать)

§ Можно заменять “плохой” запрос на N “хороших”§ Можно вообще выбросить ORM§ ^ До этого в моей практике не доходило ни у кого§ Можно выбросить плохой запрос — вдруг, никто не

заметит?


Случай на производстве №2 (тоже типичный)

§ Сайт по продаже чего-то§ Когда приходят боты, чтобы парсить контент — всё

тормозит§ “Боты” - это не Яндекс или Google, а какие-то

конкуренты, которые игнорируют robots.txt и публично доступное API


Решение №2 (довольно типичное)

§ На сайте уже стоит платный NewRelic, который умеет показывать проблемные места с хорошей степенью детализации*

§ * Для некоторых языков программирования§ Туда никто даже смотреть не стал — ботов

просто забанили по IP§ Потому что нефиг тут шастать!


Случай на производстве №3 (уже было)

§ Сайт по продаже чего-то еще§ Когда приходят боты, чтобы подбирать логины

клиентов — всё тормозит§ Боты приходят слишком умные, и по IP их забанить

невозможно — они делают по одному запросу в несколько минут с одного IP, не чаще


Решение №3 (довольно унылое)

§ Добавить в код профилирующих метрик§ Убедиться в том, что тормозит шаблонизатор§ Подумать, о замене шаблонизатора на нормальный§ Оценить трудоемкость§ Выделить общий для ботов шаблон (запросы по

HTTP/1.0, у нормальных клиентов — 1.1)§ Побанить ботов по шаблону


Случай на производстве №4 (бывает)

§ B2B-сервис, ходящий за исходным данными для расчетов на несколько внешних сайтов

§ Когда клиентов на сайт заходит много — наступает отказ в обслуживании

§ Особенно, если в то же самое время какой-нибудь из сайтов-партнеров отдает данные не слишком быстро


Решение №4 (тоже унылое)

§ Добавить в код профилирующих метрик§ Убедиться в том, что синхронные запросы к

внешним сервисам — это далеко не всегда хорошая идея (никогда, на самом деле)

§ Добавить uwsgi воркеров (пусть их будет 150)§ Скрестить пальцы


Альтернативная история

§ Убедить разработчиков переделать чудо-приложение под асинхронную модель взаимодействия с внешним тормозным миром

§ ^ Как оно и должно быть по науке§ Хочешь, чтобы что-то было сделано — сделай

сам


Найдите десять отличий

§ Во всех четырех историях есть общие черты:§ Приложение работает неоптимально§ Проблемы довольно очевидны§ У разработчиков нет времени и/или

желания разбираться с проблемами производительности

§ Технический долг (и энтропия) растет


Пара слов о социальном взаимодействии

§ Коллеги не будут вас любить:§ Вы разрушаете то, что было создано ими§ Они часто путают красоту и эффективность§ Для них вы какой-то выскочка§ У них есть более важные задачи, чем

общение с вами§ Они знают бизнес-логику, а вы - нет


Случай на производстве №5 (Н.Е.Х.)

§ B2B-сервис из случая №4§ ОДНАЖДЫ все перестало работать, а именно:§ Загрузка процессора 100%§ Несмотря на наличие SSD, база данных работает

не слишком быстро§ А приложение — и того хуже


Решение №5 (магия дружбы)

§ Метаться, кричать§ Найти, что поменялось в последние две недели

(ничего не поменялось)§ После 30-40 минут раздумий выключить в BIOS

сервера Hyper-Threading и запретить изменения частоты процессора

§ Выдохнуть


Почему это работает

§ Не будь у моей подруги с ее парнем опыта работы с системами виртуализации — фиг бы они вообще до этого додумались

§ Планировщику операционной системы тяжело в ситуации, когда ядра меняют частоту, к тому же, некоторые из ядер не существуют на самом деле

§ Планировщик двигает задачи туда-сюда


Стоп, стоп, стоп!

§ Метаться, делать другие хаотические движения, а через какое-то время решить проблему?

§ WTF?§ Факты — гипотеза — ответные меры§ Как возникла гипотеза?§ Сбор фактов, потом их анализ:§ echo t > /proc/sysrq-trigger


Немного когнитивной психологии

§ А почему именно echo t > /proc/sysrq-trigger,§ А не другая странная и непонятная мера?§ Исходим из известных нам фактов: что-то

занимает процессор§ Как посмотреть, что именно?§ В приложении — gdb thread apply all bt§ Не видим ничего необычного — спустимся ниже


Случай на производстве №6 (сложный)

§ Сервис показа мобильной рекламы§ Набор асинхронных сервисов на языке Perl§ ОДНАЖДЫ ПРЯМО НА ПРОДАКШНЕ все

перестало работать, а именно:§ Реклама перестала отдаваться, хотя партнеры

работают исправно§ На сервисах в пределах одной машины - таймауты


Решение №6 (очевидное)

§ Обвешать вообще всё метриками профайлинга, включая 3rd party асинхронные модули

§ Под “вообще всё” я имел в виду вообще всё§ Найти магическую константу MAX_PER_HOST в

одном из модулей, который, вообще-то, был задуман автором как эмуляция браузера

§ Увеличить ее с 4 до 400§ Жить спокойно до следующего падения


Почему это работает

§ Потому что это и есть нормальный инженерный подход, а именно:

§ Измерить (получить метрики)§ Выработать план (проанализировать метрики)§ Внести полезные изменения§ Снова измерить


Почему было сложно

§ Несмотря на верность в целом, описанный подход имеет ряд недостатков:§ Невозможно предсказать время его

сходимости в общем виде§ Он вообще может не сойтись в общем виде

по объективным причинам§ Альтернативные отличные идеи (“всё

переписать”, etc)


Все переписать!

§ Итак, что лучше, Perl, Ruby или PHP?§ В неравенстве Perl <> Ruby <> PHP, в конечном

счете, где-то должны находиться и вы сами§ И если вы хуже и чем Perl, и чем Ruby, и чем

PHP — у вас не получится НИЧЕГО§ Для CPU-bound задач берите что-нибудь, что

поближе к железу, чем перечисленные не-JIT-enabled скриптовые поделки*


* есть всякие наработки и для них

Случай на производстве №7 (повсеместный)

§ Клиент хостился на Хетцнере§ ОДНАЖДЫ в зеркале сломался первый диск§ Через некоторое время сломался и второй§ Когда все это заметили — данные уже были

немножко потеряны


Решение №7 (необходимое)

§ Завести бэкапы!§ При чем же тут performance?§ Pooling, compression, deduplication...§ ^ BackupPC отлично подходит, но...§ rsync очень сильно нагружает дисковую

подсистему машины-клиента§ Опция --bwlimit=500 (или сколько можете)


Почему это (не) работает

§ Зачем нужны бэкапы?§ Затем, чтобы однажды ими воспользоваться,

например...§ Развернуть систему из бэкапа целиком!§ Бэкап сотен гигабайт будет разворачиваться

несколько суток§ ^ Для начала просто задумайтесь об этом


Выводы

§ Старайтесь всегда точно знать, где вы находитесь§ Измеряйте§ Планируйте§ Не паникуйте§ В сложной ситуации делайте что-нибудь красиво§ Все хорошо будет


С вами был Александр Чистяков,главный инженер Git in Sky

[email protected]://gitinsky.com

http://meetup.com/DevOps-40

Пожалуйста, ваши вопросы.

Спасибо за внимание!

mailto:[email protected]

mailto:[email protected]

http://gitinsky.com/



http://meetup.com/DevOps-40

performance engineering stories from #fdminicon saransk

Technology