Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...Ontico
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
От репозитория до CI/CD-инфраструктуры в продакшне за неделю / Дмитрий Чумак ...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2810.html
В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.
Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.
Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.
Разбор того, что же получилось в итоге, и какие есть дальнейшие перспективы развития инфраструктуры.
Переосмысливая подход к инфраструктурному коду / Евгений Пивень (IPONWEB)Ontico
HighLoad++ 2017
Зал «Дели + Калькутта», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3033.html
Legacy-код - это проблема, которая затрагивает не только программный, но и инфраструктурный код. Причём невозможность двигаться вперёд и большие риски, связанные с изменением логики, грозят ничуть не меньшими потерями.
Я расскажу о том, как в нашей компании мы проводили рефакторинг и модулирование огромного куска Puppet-кода, который обслуживает множество проектов, вводили тестирование, и к чему это всё привело.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
Пряморукий DNS: делаем правильно / Лев Николаев (Макснет)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 15:00
Тезисы:
http://rootconf.ru/2017/abstracts/2569.html
Большинство администраторов, когда становятся уже слишком серьезными, чтобы просто так использовать DNS-сервера провайдера, часто выбирают bind в качестве DNS-сервера. Дальше bind подталкивает их к использованию не самых хороших практик, например, совмещению ролей резольвера и авторитетного DNS.
Несмотря на все свои крутые преимущества, вроде split horizon, bind, к сожалению, далек по своей производительности от оптимального выбора.
...
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...Ontico
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Как не положить тысячи серверов с помощью системы централизованного управлени...Ontico
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
От репозитория до CI/CD-инфраструктуры в продакшне за неделю / Дмитрий Чумак ...Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 18:00
Тезисы:
http://rootconf.ru/2017/abstracts/2810.html
В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.
Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.
Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.
Разбор того, что же получилось в итоге, и какие есть дальнейшие перспективы развития инфраструктуры.
Переосмысливая подход к инфраструктурному коду / Евгений Пивень (IPONWEB)Ontico
HighLoad++ 2017
Зал «Дели + Калькутта», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3033.html
Legacy-код - это проблема, которая затрагивает не только программный, но и инфраструктурный код. Причём невозможность двигаться вперёд и большие риски, связанные с изменением логики, грозят ничуть не меньшими потерями.
Я расскажу о том, как в нашей компании мы проводили рефакторинг и модулирование огромного куска Puppet-кода, который обслуживает множество проектов, вводили тестирование, и к чему это всё привело.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
Пряморукий DNS: делаем правильно / Лев Николаев (Макснет)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 15:00
Тезисы:
http://rootconf.ru/2017/abstracts/2569.html
Большинство администраторов, когда становятся уже слишком серьезными, чтобы просто так использовать DNS-сервера провайдера, часто выбирают bind в качестве DNS-сервера. Дальше bind подталкивает их к использованию не самых хороших практик, например, совмещению ролей резольвера и авторитетного DNS.
Несмотря на все свои крутые преимущества, вроде split horizon, bind, к сожалению, далек по своей производительности от оптимального выбора.
...
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Auto Brands in the US on Social Media During Q2 2015Unmetric
Vehicle sales in North America are approaching record levels and people are opting for larger cars do to lower fuel costs. On the other hand, satisfaction with auto brands is at a five year low. We took a look at how the top US car makers fared on Facebook, Twitter and Instagram in the second quarter of 2015. See how they handled complaints and questions from customers and what kind of content was truly resonating with fans.
PHP performance 101: so you need to use a databaseLeon Fayer
Being involved in performance audits on systems of every size, from start-up sites hacked together overnight, to a ginormous applications built by world-recognized brand companies, I’ve seen a lot of interesting (and sometimes very unique) performance issues in every level of the stack: code, architecture, databases (sometimes all of the above). But there are a few particular, very “Performance 101″, issues that (unfortunately) appear in a lot of code bases. In this talk I present the most common database-related performance bottlenecks that can happen in most PHP applications.
Lately, I've been having a lot of conversations with conference goers. Most attend numerous conferences, have great hallway discussions and yet are too hesitant to submit a proposal with their story. The reasons vary, but the hesitation (or even fear) to present a topic publicly is pretty common in our industry. Being a fairly new speaker myself, I can relate to a lot of these concerns. Hence the reason for this talk.
This talk covers a few of the more common objections to public speaking, recommendations on how to address them as well as tips for new (and maybe veteran) speakers. Everyone has a story. That story should be heard.
ThemeForest: Как пробиться и стоит ли игра свеч? | Odessa Frontend Meetup #9OdessaFrontend
Роман Пшеничный делится своим 4-х летним опытом работы разработки шаблонов для площадки ThemeForest. Рассказывает плюсы, минусы, подводные камни, а так же причины почему большинство желающих не могут попасть на этот рынок. И показывает рабочий процесс создания шаблона и используемые технологии.
Евгений Жарков "Как быть хорошим фронтенд-разработчиком"Fwdays
Как искать и выбирать оптимальные решения? Для одной задачи подойдет React, для другой - Zepto. Сегодня вы пишите для браузера, завтра думаете, как использовать native-ресурсы iOS.
Не все технологии, которые удобны разработчику, могут дать удобство конечному пользователю.
Я расскажу о балансе, который позволяет бизнесу получать результат, а разработчику - решение.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
Serghei Iakovlev "Chaos engineering in action"Fwdays
Let's talk about what chaos engineering is and how this discipline can be applied in projects where PHP is used as the main language.
Among other things, we will cover the following topics:
What problems does chaos engineering solve?
What are the solutions exist?
How to develop your own solution?
What is a controlled failover?
A little about ZendEngine and what tools are out of the box?
A bit about chaos design.
A bit about the code leading to chaos.
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Performance engineering stories from #fdminicon Saransk
1. Несколько историй из жизни
Performance Engineer'а
Александр Чистяков,
главный инженер Git in Sky,
2014
Как я съел кусок мыла
Александр Чистяков,
главный инженер Git in Sky,
2014
2. Давайте познакомимся
§ Меня зовут Саша
§ Я работаю главным инженером в компании Git in Sky
§ Мы занимаемся эксплуатацией веб-проектов,
помощью в разработке веб-проектов, собственно
разработкой веб-проектов и автоматизацией веб-
проектов
§ Во всем этом приходится участвовать мне
Несколько историй из жизни Performance Engineer'а. 2014
3. А в чем участвуете вы?
§ Веб-разработка?
§ Эксплуатация веб-сайтов?
§ Поддержка проекта, написанного непонятно кем?
§ Борьба с хабраэффектом?
§ Принятие решений об аренде/покупке серверов?
§ Еще пока не определились, всё такое вкусное?
Несколько историй из жизни Performance Engineer'а. 2014
4. О чем пойдет речь?
§ Кто такие performance engineers и зачем они нужны
§ Как справиться с хабраэффектом
§ Сколько серверов нужно, чтобы вкрутить одну
лампочку
§ Что лучше: MySQL или MongoDB? PHP, Perl или
Ruby?
§ Однажды у моей подруги с ее парнем...
Несколько историй из жизни Performance Engineer'а. 2014
5. Кто такой performance engineer?
§ Это человек, который делает performance
engineering
§ http://en.wikipedia.org/wiki/Performance_engineering
§ ^ многа букв
§ Человек, который знает, как все устроено внутри не
в терминах бизнес-логики приложения
Несколько историй из жизни Performance Engineer'а. 2014
6. Как бороться с хабраэффектом
§ Я испытываю хабраэффект почти каждый раз, когда
открываю статью на Хабре
§ Способы борьбы:
§ Не верьте в магию
§ Не читайте статьи на Хабре
§ Знание — сила
§ (на самом деле, сила это масса на ускорение)
Несколько историй из жизни Performance Engineer'а. 2014
8. Проблемы типичного веб-проекта
§ Непосредственно вытекают из его структуры
§ Подразделяются на:
§ ВНЕЗАПНО ничего не работает
§ Всё тормозит!
§ Мы арендовали c3.xlarge, а оно все равно
тормозит!
§ Данные куда-то пропали
Несколько историй из жизни Performance Engineer'а. 2014
9. Переходим к практике
§ Краткое содержание следующих серий:
§ Описание проблемы, происшедшей у моей
подруги с ее парнем
§ Описание пути решения проблемы
§ Несколько слов о том, чем именно
руководствовались при решении проблемы,
и почему всё удалось (или не удалось)
Несколько историй из жизни Performance Engineer'а. 2014
10. Случай на производстве №1 (типичный)
§ Сайт-новостник, написанный с использованием
UMI.CMS древней версии
§ Проблема: медленно работает админка, время
от времени начинает медленно работать всё
§ “Медленно” - страница генерируется десятки
секунд
Несколько историй из жизни Performance Engineer'а. 2014
11. Решение №1 (типичнее некуда)
§ Включить MySQL slow queries log
§ На всякий случай добавить в код вызовы
профайлинга (подойдет что угодно — например,
записывать скорость генерации страницы в лог, в
базу данных, в PINBA, в Graphite или еще куда-то)
§ Убедиться, что проблема в запросах к БД
§ Найти долгий запрос и посмотреть его query plan
Несколько историй из жизни Performance Engineer'а. 2014
12. Почему (не) работает (тоже типично)
§ Запрос сгенерирован ORM и делает фиг знает что
§ На самом деле, никто не знает, что именно он
делает, но он джойнит две огромных таблицы,
накладывает условия и сортирует результат
§ Индексы не работают, да и не могут
§ Такие сортировки — хуже всего для СУБД
§ Разработчики не знают, как быть
Несколько историй из жизни Performance Engineer'а. 2014
13. Альтернативная история
§ Можно хакнуть ORM и заменять “плохой” запрос на
“хороший” (резалтсеты должны совпадать)
§ Можно заменять “плохой” запрос на N “хороших”
§ Можно вообще выбросить ORM
§ ^ До этого в моей практике не доходило ни у кого
§ Можно выбросить плохой запрос — вдруг, никто не
заметит?
Несколько историй из жизни Performance Engineer'а. 2014
14. Случай на производстве №2 (тоже типичный)
§ Сайт по продаже чего-то
§ Когда приходят боты, чтобы парсить контент — всё
тормозит
§ “Боты” - это не Яндекс или Google, а какие-то
конкуренты, которые игнорируют robots.txt и
публично доступное API
Несколько историй из жизни Performance Engineer'а. 2014
15. Решение №2 (довольно типичное)
§ На сайте уже стоит платный NewRelic, который
умеет показывать проблемные места с
хорошей степенью детализации*
§ * Для некоторых языков программирования
§ Туда никто даже смотреть не стал — ботов
просто забанили по IP
§ Потому что нефиг тут шастать!
Несколько историй из жизни Performance Engineer'а. 2014
16. Случай на производстве №3 (уже было)
§ Сайт по продаже чего-то еще
§ Когда приходят боты, чтобы подбирать логины
клиентов — всё тормозит
§ Боты приходят слишком умные, и по IP их забанить
невозможно — они делают по одному запросу в
несколько минут с одного IP, не чаще
Несколько историй из жизни Performance Engineer'а. 2014
17. Решение №3 (довольно унылое)
§ Добавить в код профилирующих метрик
§ Убедиться в том, что тормозит шаблонизатор
§ Подумать, о замене шаблонизатора на нормальный
§ Оценить трудоемкость
§ Выделить общий для ботов шаблон (запросы по
HTTP/1.0, у нормальных клиентов — 1.1)
§ Побанить ботов по шаблону
Несколько историй из жизни Performance Engineer'а. 2014
18. Случай на производстве №4 (бывает)
§ B2B-сервис, ходящий за исходным данными для
расчетов на несколько внешних сайтов
§ Когда клиентов на сайт заходит много — наступает
отказ в обслуживании
§ Особенно, если в то же самое время какой-нибудь
из сайтов-партнеров отдает данные не слишком
быстро
Несколько историй из жизни Performance Engineer'а. 2014
19. Решение №4 (тоже унылое)
§ Добавить в код профилирующих метрик
§ Убедиться в том, что синхронные запросы к
внешним сервисам — это далеко не всегда
хорошая идея (никогда, на самом деле)
§ Добавить uwsgi воркеров (пусть их будет 150)
§ Скрестить пальцы
Несколько историй из жизни Performance Engineer'а. 2014
20. Альтернативная история
§ Убедить разработчиков переделать
чудо-приложение под асинхронную модель
взаимодействия с внешним тормозным
миром
§ ^ Как оно и должно быть по науке
§ Хочешь, чтобы что-то было сделано — сделай
сам
Несколько историй из жизни Performance Engineer'а. 2014
21. Найдите десять отличий
§ Во всех четырех историях есть общие черты:
§ Приложение работает неоптимально
§ Проблемы довольно очевидны
§ У разработчиков нет времени и/или
желания разбираться с проблемами
производительности
§ Технический долг (и энтропия) растет
Несколько историй из жизни Performance Engineer'а. 2014
22. Пара слов о социальном взаимодействии
§ Коллеги не будут вас любить:
§ Вы разрушаете то, что было создано ими
§ Они часто путают красоту и эффективность
§ Для них вы какой-то выскочка
§ У них есть более важные задачи, чем
общение с вами
§ Они знают бизнес-логику, а вы - нет
Несколько историй из жизни Performance Engineer'а. 2014
23. Случай на производстве №5 (Н.Е.Х.)
§ B2B-сервис из случая №4
§ ОДНАЖДЫ все перестало работать, а именно:
§ Загрузка процессора 100%
§ Несмотря на наличие SSD, база данных работает
не слишком быстро
§ А приложение — и того хуже
Несколько историй из жизни Performance Engineer'а. 2014
24. Решение №5 (магия дружбы)
§ Метаться, кричать
§ Найти, что поменялось в последние две недели
(ничего не поменялось)
§ После 30-40 минут раздумий выключить в BIOS
сервера Hyper-Threading и запретить
изменения частоты процессора
§ Выдохнуть
Несколько историй из жизни Performance Engineer'а. 2014
25. Почему это работает
§ Не будь у моей подруги с ее парнем опыта
работы с системами виртуализации — фиг
бы они вообще до этого додумались
§ Планировщику операционной системы тяжело
в ситуации, когда ядра меняют частоту,
к тому же, некоторые из ядер не существуют
на самом деле
§ Планировщик двигает задачи туда-сюда
Несколько историй из жизни Performance Engineer'а. 2014
26. Стоп, стоп, стоп!
§ Метаться, делать другие хаотические движения,
а через какое-то время решить проблему?
§ WTF?
§ Факты — гипотеза — ответные меры
§ Как возникла гипотеза?
§ Сбор фактов, потом их анализ:
§ echo t > /proc/sysrq-trigger
Несколько историй из жизни Performance Engineer'а. 2014
27. Немного когнитивной психологии
§ А почему именно echo t > /proc/sysrq-trigger,
§ А не другая странная и непонятная мера?
§ Исходим из известных нам фактов: что-то
занимает процессор
§ Как посмотреть, что именно?
§ В приложении — gdb thread apply all bt
§ Не видим ничего необычного — спустимся ниже
Несколько историй из жизни Performance Engineer'а. 2014
28. Случай на производстве №6 (сложный)
§ Сервис показа мобильной рекламы
§ Набор асинхронных сервисов на языке Perl
§ ОДНАЖДЫ ПРЯМО НА ПРОДАКШНЕ все
перестало работать, а именно:
§ Реклама перестала отдаваться, хотя партнеры
работают исправно
§ На сервисах в пределах одной машины - таймауты
Несколько историй из жизни Performance Engineer'а. 2014
29. Решение №6 (очевидное)
§ Обвешать вообще всё метриками профайлинга,
включая 3rd party асинхронные модули
§ Под “вообще всё” я имел в виду вообще всё
§ Найти магическую константу MAX_PER_HOST в
одном из модулей, который, вообще-то, был
задуман автором как эмуляция браузера
§ Увеличить ее с 4 до 400
§ Жить спокойно до следующего падения
Несколько историй из жизни Performance Engineer'а. 2014
30. Почему это работает
§ Потому что это и есть нормальный инженерный
подход, а именно:
§ Измерить (получить метрики)
§ Выработать план (проанализировать метрики)
§ Внести полезные изменения
§ Снова измерить
Несколько историй из жизни Performance Engineer'а. 2014
31. Почему было сложно
§ Несмотря на верность в целом, описанный
подход имеет ряд недостатков:
§ Невозможно предсказать время его
сходимости в общем виде
§ Он вообще может не сойтись в общем виде
по объективным причинам
§ Альтернативные отличные идеи (“всё
переписать”, etc)
Несколько историй из жизни Performance Engineer'а. 2014
32. Все переписать!
§ Итак, что лучше, Perl, Ruby или PHP?
§ В неравенстве Perl <> Ruby <> PHP, в конечном
счете, где-то должны находиться и вы сами
§ И если вы хуже и чем Perl, и чем Ruby, и чем
PHP — у вас не получится НИЧЕГО
§ Для CPU-bound задач берите что-нибудь, что
поближе к железу, чем перечисленные
не-JIT-enabled скриптовые поделки*
Несколько историй из жизни Performance Engineer'а. 2014
* есть всякие наработки и для них
33. Случай на производстве №7 (повсеместный)
§ Клиент хостился на Хетцнере
§ ОДНАЖДЫ в зеркале сломался первый диск
§ Через некоторое время сломался и второй
§ Когда все это заметили — данные уже были
немножко потеряны
Несколько историй из жизни Performance Engineer'а. 2014
34. Решение №7 (необходимое)
§ Завести бэкапы!
§ При чем же тут performance?
§ Pooling, compression, deduplication...
§ ^ BackupPC отлично подходит, но...
§ rsync очень сильно нагружает дисковую
подсистему машины-клиента
§ Опция --bwlimit=500 (или сколько можете)
Несколько историй из жизни Performance Engineer'а. 2014
35. Почему это (не) работает
§ Зачем нужны бэкапы?
§ Затем, чтобы однажды ими воспользоваться,
например...
§ Развернуть систему из бэкапа целиком!
§ Бэкап сотен гигабайт будет разворачиваться
несколько суток
§ ^ Для начала просто задумайтесь об этом
Несколько историй из жизни Performance Engineer'а. 2014
36. Выводы
§ Старайтесь всегда точно знать, где вы находитесь
§ Измеряйте
§ Планируйте
§ Не паникуйте
§ В сложной ситуации делайте что-нибудь красиво
§ Все хорошо будет
Несколько историй из жизни Performance Engineer'а. 2014
37. С вами был Александр Чистяков,
главный инженер Git in Sky
alex@gitinsky.com
http://gitinsky.com
http://meetup.com/DevOps-40
Пожалуйста, ваши вопросы.
Спасибо за внимание!