Reinventing the wheel - why do it and how to feel good about it - Julik Tarkh...Ruby Meditation
Talk of Julik Tarkhanov, senior backend engineer, WeTransfer, Amsterdam, at Ruby Meditation #28 Kyiv 26.10.2019
Next conference - http://www.rubymeditation.com/
It is often a choice, sometimes a whim, and sometimes an act of desperation. We idolise reuse while sometimes the road not taken is just as exciting. Let's chat about where it is appropriate to "do the thing again", take the scenic route and enjoy the view.
Announcements and conference materials https://www.fb.me/RubyMeditation
News https://twitter.com/RubyMeditation
Photos https://www.instagram.com/RubyMeditation
The stream of Ruby conferences (not just ours) https://t.me/RubyMeditation
* The channel of the organizers of the meetup https://t.me/incredevly
Reinventing the wheel - why do it and how to feel good about it - Julik Tarkh...Ruby Meditation
Talk of Julik Tarkhanov, senior backend engineer, WeTransfer, Amsterdam, at Ruby Meditation #28 Kyiv 26.10.2019
Next conference - http://www.rubymeditation.com/
It is often a choice, sometimes a whim, and sometimes an act of desperation. We idolise reuse while sometimes the road not taken is just as exciting. Let's chat about where it is appropriate to "do the thing again", take the scenic route and enjoy the view.
Announcements and conference materials https://www.fb.me/RubyMeditation
News https://twitter.com/RubyMeditation
Photos https://www.instagram.com/RubyMeditation
The stream of Ruby conferences (not just ours) https://t.me/RubyMeditation
* The channel of the organizers of the meetup https://t.me/incredevly
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Язык Lua — секреты производительности / Ник Заварицкий (Mail.ru)Ontico
Lua — высокоуровневый язык, похожий на Python/JS, но существенно более простой. Он гибкий и при этом очень быстрый.
Многие слышали про OpenResty. Это решение для разработки Nginx модулей на Lua. Cloudflare, крупнейший CDN/anti-DDOS провайдер, как раз работает на OpenResty.
У нас была задача валидации данных на соответствие схеме; мы переписали валидацию с Си на Lua и получили ускорение в 4 раза (за счет JIT-компиляции).
Что будет в докладе:
* краткое введение в язык Lua;
* как работает трассирующий JIT-компилятор Lua;
* как писать быстрый код, искать и устранять проблемы с производительностью;
* наш опыт: как мы ускорились в 4 раза, переписав валидацию с Си на Lua.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Aviasales: миграция поискового движка в docker / Дмитрий Кузьменков (Aviasales)Ontico
* Yasen (Yet Another Search Engine) – первоначальная архитектура поискового движка.
* Немного о старой схеме деплоя и её боли – buildbot, chef, git, monit, haproxy.
* Docker – простота и мощь в одной команде.
* Настраиваем запуск демона – что нужно знать.
* Dockerfile – проблемы и решения.
* Swarm, Kubernetes, Rancher – обзор вариантов оркестрации.
* Простой путь – docker-compose, и как его готовить.
* Разбираемся с сетью – bridge, host, overlay, macvlan, none.
* Root или не root в контейнере? Выбираем подходящее решение.
* Shared volumes и проблема права доступа к файлам.
* User namespaces – как и зачем?
* Docker и linux capabilities – добавляем безопасности.
* Нюансы ограничения ресурсов контейнеру: memory, cpu, swap.
* Stateful & Stateless в docker
* Автоматизация деплоя через docker-compose.
* Итоговая архитектура и процесс выкатки в production.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Лекция "Actor Model" в рамках магистерского курса "Параллельные вычисления" на кафедре КСПТ: Actor Model, Use Cases, Futures and Promises, Reactive Streams.
Фреймворк Akka и его использование в ЯндексеVadim Tsesko
Доклад с JPoint 2014 (http://javapoint.ru).
Краткое содержание:
* Actor Model на примере Akka
* Происхождение
* Концепции и API
* Примеры кода
* Примеры систем в Яндекс
* Конвейерная обработка данных
* Реактивные иерархические системы
* Опыт разработки и эксплуатации
* Подводные камни
* Проблемы и некоторые решения
* Дополнительные тулы
JVM: краткий курс общей анатомии, JPoint 2016 Conference EditionNikita Lipsky
Говоря о Java, мы подразумеваем как минимум две вещи: JVM (виртуальную Java-машину) и Java-байткод, который исполняется на этой машине.
Внутреннее устройство JVM непростое, но очень важно понимать, из каких частей она состоит, какая часть за что отвечает и как это все вместе работает хотя бы в самых общих чертах. Эти знания помогут вам в понимании того, как работает ваша программа и как можно улучшить ее работу.
В этом докладе мы не будем лезть в кишки какой-то конкретной реализации JVM, однако мы покажем где у JVM кишки расположены, а также где находятся и для чего служат ее печень, сердце, почки, мозг и другие органы.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Язык Lua — секреты производительности / Ник Заварицкий (Mail.ru)Ontico
Lua — высокоуровневый язык, похожий на Python/JS, но существенно более простой. Он гибкий и при этом очень быстрый.
Многие слышали про OpenResty. Это решение для разработки Nginx модулей на Lua. Cloudflare, крупнейший CDN/anti-DDOS провайдер, как раз работает на OpenResty.
У нас была задача валидации данных на соответствие схеме; мы переписали валидацию с Си на Lua и получили ускорение в 4 раза (за счет JIT-компиляции).
Что будет в докладе:
* краткое введение в язык Lua;
* как работает трассирующий JIT-компилятор Lua;
* как писать быстрый код, искать и устранять проблемы с производительностью;
* наш опыт: как мы ускорились в 4 раза, переписав валидацию с Си на Lua.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Aviasales: миграция поискового движка в docker / Дмитрий Кузьменков (Aviasales)Ontico
* Yasen (Yet Another Search Engine) – первоначальная архитектура поискового движка.
* Немного о старой схеме деплоя и её боли – buildbot, chef, git, monit, haproxy.
* Docker – простота и мощь в одной команде.
* Настраиваем запуск демона – что нужно знать.
* Dockerfile – проблемы и решения.
* Swarm, Kubernetes, Rancher – обзор вариантов оркестрации.
* Простой путь – docker-compose, и как его готовить.
* Разбираемся с сетью – bridge, host, overlay, macvlan, none.
* Root или не root в контейнере? Выбираем подходящее решение.
* Shared volumes и проблема права доступа к файлам.
* User namespaces – как и зачем?
* Docker и linux capabilities – добавляем безопасности.
* Нюансы ограничения ресурсов контейнеру: memory, cpu, swap.
* Stateful & Stateless в docker
* Автоматизация деплоя через docker-compose.
* Итоговая архитектура и процесс выкатки в production.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Лекция "Actor Model" в рамках магистерского курса "Параллельные вычисления" на кафедре КСПТ: Actor Model, Use Cases, Futures and Promises, Reactive Streams.
Фреймворк Akka и его использование в ЯндексеVadim Tsesko
Доклад с JPoint 2014 (http://javapoint.ru).
Краткое содержание:
* Actor Model на примере Akka
* Происхождение
* Концепции и API
* Примеры кода
* Примеры систем в Яндекс
* Конвейерная обработка данных
* Реактивные иерархические системы
* Опыт разработки и эксплуатации
* Подводные камни
* Проблемы и некоторые решения
* Дополнительные тулы
JVM: краткий курс общей анатомии, JPoint 2016 Conference EditionNikita Lipsky
Говоря о Java, мы подразумеваем как минимум две вещи: JVM (виртуальную Java-машину) и Java-байткод, который исполняется на этой машине.
Внутреннее устройство JVM непростое, но очень важно понимать, из каких частей она состоит, какая часть за что отвечает и как это все вместе работает хотя бы в самых общих чертах. Эти знания помогут вам в понимании того, как работает ваша программа и как можно улучшить ее работу.
В этом докладе мы не будем лезть в кишки какой-то конкретной реализации JVM, однако мы покажем где у JVM кишки расположены, а также где находятся и для чего служат ее печень, сердце, почки, мозг и другие органы.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Многие аналитики предрекают реактивному программированию большое будущее в решении задач Mobile и Big Data.
TypeSafe, разработчики языка Scala, создали многообещающий реактивный фреймворк Akka, который "дружит" с Java.
Чем он может быть интересен Java-разработчикам? Сможет ли Akka+Java конкурировать с Akka+Scala? И как ей в этом помогут новые фичи Java 8?
Об этом я расскажу в своем докладе "Посмотрим на Акку-Джаву".
How to run Real Time processing on Big Data / Ron Zavner (GigaSpaces)Ontico
This document discusses how GigaSpaces software provides real-time processing of big data through its in-memory data grid technology. It highlights challenges with current tier-based architectures in meeting demands for real-time analytics at scale. GigaSpaces' XAP platform is presented as a solution that scales the data, messaging, and application tiers in memory to enable real-time querying and analysis of large datasets across multiple sites. The document provides an overview of XAP features and capabilities as well as example use cases from customers in e-commerce and banking.
Slides from http://www.meetup.com/Reactive-Systems-Hamburg/events/232887060
Barys and Simon talked about Akka Cluster. Cluster Sharding allows to transparently distribute work in an Akka cluster with automatic balancing, migration of workers and automatic restart in case of errors. Cluster PubSub offers the publish/subscribe pattern. Akka Distributed Data offers eventually consistent data structures across the cluster, that allow for keeping the cluster's state.
They talked about the Akka Modules and explained how they interplay. Finally, they shared what Risk.Ident have learned running a reactive application based on Akka Cluster in production for almost a year.
Никита Цуканов "Параллелизм и распределённые вычисления на акторах с Akka.net"Yulia Tsisyk
Доклад с митапа MSK .NET Community (http://mskdotnet.org).
В современном мире уже нельзя писать код, который работает на одном компьютере на одном процессорном ядре и имеет монопольный доступ к данным. Опытом борьбы с трудностями при написании многопоточного кода поделится Никита Цуканов.
Доклад "Параллелизм и распределённые вычисления на акторах с Akka.NET" рассчитан на неподготовленного слушателя, ранее не имевшего дело с акторами, и является улучшенной и дополненной версией доклада с питерского DotNext. 11 августа речь пойдёт непосредственно об акторной модели и её реализации в Akka.NET, особенностях юнит-тестирования, акторах с сохраняемым состоянием, а так же об интеграции всей этой машинерии с имеющимся приложением и ASP.NET.
Multithreading in java past and actualYevgen Levik
In this talk I’d like to give you an overview of java.util.concurrent package and represent useful Java concurrency tools. I’ll cover the core functionality and the state-of-the-art API (Executors, Accumulators, StampedLock etc).
Simple examples in github (https://github.com/levik666/OverviewInJavaUtilConcurrent)
This document discusses how implicits work in Scala, including how implicit conversions, parameters, and classes are resolved by the compiler. It explains how the compiler searches for implicits, potentially including extended implicit scopes, and how it handles recursion and complexity to avoid stack overflow errors. It also discusses how IDEs can help with implicits by analyzing available conversions and parameter types.
The document discusses Scala implicits, including how they work, how IDEs can help with them, and possibilities to improve their performance. It covers implicit conversions, extension methods, implicit parameters, and how the compiler handles implicit resolution and type inference. The presenter advocates using implicits as a key Scala feature while also choosing tools that help debug issues and analyze available implicit conversions.
The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive function. Exercise causes chemical changes in the brain that may help protect against mental illness and improve symptoms for those who already suffer from conditions like anxiety and depression.
The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive functioning. Exercise boosts blood flow, releases endorphins, and promotes changes in the brain which help regulate emotions and stress levels.
Оптимизация производительности фронтенда / Игорь Алексеенко (HTML Academy)Ontico
РИТ++ 2017, Frontend Сonf
Зал Дели + Калькутта, 6 июня, 14:00
Тезисы:
http://frontendconf.ru/2017/abstracts/2524.html
В этом докладе я покажу на примерах, в каких случаях нужно делать ставку на кэширование, а в каких можно довериться процессору, и как это может помочь оптимизировать производительность сложного фронтенд-приложения.
(Не) преждевременная оптимизация проекта на Unreal Engine 4 / Владимир Алямки...DevGAMM Conference
В рамках лекции будет рассмотрен ряд уже имеющихся инструментов оптимизации на движке, о которых стоит знать, начиная работу над проектом. Доклад также затрагивает практическую основу и причины таких подходов, совмещая тематику архитектуры современных игровых движков и механик рендера сцены.
Мой доклад о создании yeoman генератора своими руками на митапе 4front. Рассказ о том, как yeoman.io упрощает жизнь, спасает от рутины и экономит время.
Обзор технологии и типичных граблей.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Similar to Akka: как я перестал бояться и полюбил асинхронный код (20)
Akka: как я перестал бояться и полюбил асинхронный код
1. Как я перестал бояться и полюбил
асинхронный код
JUG@VRN, 2014
Гребенников Роман,
Sociohub
2. Содержание
● Модель акторов:
o зачем она нужна;
o что это такое;
o Akka 2 и Scala;
o какие возможности даёт.
● Пример системы:
o система сбора и парсинга данных.
● Личный опыт:
o типичные ошибки;
o подводные камни;
o производительность;
o перспективы.
3. Free lunch is over
Одно ядро, один поток - путь в никуда:
[1]: http://www.gotw.ca/publications/concurrency-ddj.htm
[2]: PassMark, http://www.cpubenchmark.net
4. Free lunch is over
Одно ядро, один поток - путь в никуда:
[1]: http://www.gotw.ca/publications/concurrency-ddj.htm
[2]: PassMark, http://www.cpubenchmark.net
5. Concurrency vs Parallelism
[1]: Rob Pike: Concurrency is not Parallelism (it's better!), http://concur.rspace.googlecode.com/hg/talk/concur.html
6. Concurrency vs Parallelism
Parallel programming
строго одновременное исполнение
нескольких задач
[1]: Rob Pike: Concurrency is not Parallelism (it's better!), http://concur.rspace.googlecode.com/hg/talk/concur.html
7. Concurrency vs Parallelism
Concurrent programming
композиция независимо
выполняющихся задач
(не обязательно параллельно)
Parallel programming
строго одновременное исполнение
нескольких задач
[1]: Rob Pike: Concurrency is not Parallelism (it's better!), http://concur.rspace.googlecode.com/hg/talk/concur.html
8. Concurrency vs Parallelism
Concurrent programming
композиция независимо
выполняющихся задач
(не обязательно параллельно)
Parallel programming
строго одновременное исполнение
нескольких задач
[1]: Rob Pike: Concurrency is not Parallelism (it's better!), http://concur.rspace.googlecode.com/hg/talk/concur.html
Всё это сложно
14. Зачем нужны акторы?
● Чтобы перестать думать о плохом:
o блокировки, race conditions, дедлоки;
o shared state, state visibility;
o потоки, concurrent collections и т.д.
15. Зачем нужны акторы?
● Чтобы перестать думать о плохом:
o блокировки, race conditions, дедлоки;
o shared state, state visibility;
o потоки, concurrent collections и т.д.
● И начать думать о хорошем:
o single execution flow:
актор работает последовательно;
o слабая связанность всех компонентов:
легко тестировать;
o асинхронность:
больше никакого Await;
o нет никакого shared mutable state.
16. Зачем нужны акторы?
● Чтобы перестать думать о плохом:
o блокировки, race conditions, дедлоки;
o shared state, state visibility;
o потоки, concurrent collections и т.д.
● Легкость масштабирования:
o часть платформы, не надо ничего изобретать;
o есть восстановление после сбоев: “let it crash”.
● И начать думать о хорошем:
o single execution flow:
актор работает последовательно;
o слабая связанность всех компонентов:
легко тестировать;
o асинхронность:
больше никакого Await;
o нет никакого shared mutable state.
17. Модель акторов
● Придумана в 1972 году, до сих пор актуальна [1]
● Стала популярной благодаря Erlang
● Всё - актор, даже небо, даже звезды
[1]: http://letitcrash.com/post/20964174345/carl-hewitt-explains-the-essence-of-the-actor
18. Модель акторов
● Придумана в 1972 году, до сих пор актуальна [1]
● Стала популярной благодаря Erlang
● Всё - актор, даже небо, даже звезды
[1]: http://letitcrash.com/post/20964174345/carl-hewitt-explains-the-essence-of-the-actor
● Акторы:
o функционируют параллельно;
o асинхронно обмениваются сообщениями;
o имеют персональный адрес и почтовый ящик.
● при получении сообщения можно:
o отправить новое сообщение другим акторам;
o создать новых акторов;
o изменить свое поведение для следующего сообщения.
● Напоминает Email
19. Akka
● Jonas Bonér
o Java champion;
o Terracotta JVM clustering,
JRockit JVM, AspectWerkz AOP,
Eclipse AspectJ.
● Ресурсы
o http://akka.io/docs/
o http://letitcrash.com/
● Код
o http://github.com/akka/akka
o Apache 2.0 License
o Scala API, Java API
Áhkká (Lule Sami: "old woman")
21. Actor внутри
ActorRef
Actor
Почтовый ящик
Указывает на актора.
Умеет класть сообщения в ящик.
Ваш код тут
Берет сообщения по-одному.
Что-то с ними делает.
Единственный способ взаимодействия -
отправка сообщения. Во внутренности
актора доступа нет ни у кого.
23. Почтовые ящики
Пути как в файловой системе:
● akka://system/user/foo/bar
● akka.tcp://system@srv.example.com/user/foo/bar
24. Почтовые ящики
Пути как в файловой системе:
● akka://system/user/foo/bar
● akka.tcp://system@srv.example.com/user/foo/bar
Выбор актора:
● каждый актор знает себя, родителя и детей;
● акторов можно выбирать по пути из ActorRegistry:
25. Почтовые ящики
Пути как в файловой системе:
● akka://system/user/foo/bar
● akka.tcp://system@srv.example.com/user/foo/bar
Выбор актора:
● каждый актор знает себя, родителя и детей;
● акторов можно выбирать по пути из ActorRegistry:
Типы:
● UnboundedMailbox;
● BoundedMailbox;
● UnboundedPriorityMailbox;
● BoundedPriorityMailbox.
27. Диспетчеры
● Актор != поток
поток 1
поток 2
A1
A2
A4 A1
A1 A2
A4 A4A1
A3
● Каждый актор жив, только когда работает
● В остальное время он освобождает поток
28. Диспетчеры
● Актор != поток
поток 1
поток 2
A1
A2
A4 A1
A1 A2
A4 A4A1
A3
● Каждый актор жив, только когда работает
● В остальное время он освобождает поток
● Диспетчер занимается раскладыванием акторов
по потокам:
o Dispatcher;
o PinnedDispatcher;
o BalancingDispatcher;
o CallingThreadDispatcher.
29. Диспетчеры
● Актор != поток
поток 1
поток 2
A1
A2
A4 A1
A1 A2
A4 A4A1
A3
● Каждый актор жив, только когда работает
● В остальное время он освобождает поток
● Диспетчер занимается раскладыванием акторов
по потокам:
o Dispatcher;
o PinnedDispatcher;
o BalancingDispatcher;
o CallingThreadDispatcher.
● Для непосредственного исполнения:
o fork-join-executor;
o thread-pool-executor.
30. Падший актор
● Код иногда ломается
● Как жить дальше и что делать?
ActorRef
Parent
Actor
MessageBox
31. Падший актор
● Код иногда ломается
● Как жить дальше и что делать?
ActorRef
Parent
Actor
MessageBox
32. Падший актор
● Код иногда ломается
● Как жить дальше и что делать?
ActorRef
Parent
33. Падший актор
● Код иногда ломается
● Как жить дальше и что делать?
ActorRef
Parent
deadLetters
Могильник для
потерянных сообщений
34. Падший актор
● Код иногда ломается
● Как жить дальше и что делать?
ActorRef
Parent
deadLetters
Могильник для
потерянных сообщений
● И что?
35. Supervision
● Можно делать иерархии акторов
● Каждый актор в ответе за своих детей
● Упавшего ребенка можно:
36. Supervision
● Можно делать иерархии акторов
● Каждый актор в ответе за своих детей
● Упавшего ребенка можно:
● Stop: остановить;
● Restart: перезапустить;
● Continue: оставить полу-лежачим;
● Escalate: передать обработку выше.
37. Supervision
● Можно делать иерархии акторов
● Каждый актор в ответе за своих детей
● Упавшего ребенка можно:
● Stop: остановить;
● Restart: перезапустить;
● Continue: оставить полу-лежачим;
● Escalate: передать обработку выше.
● Решение рекурсивно
● Есть хуки preStart, preRestart, postStop, etc.
38. Supervision
● Можно делать иерархии акторов
● Каждый актор в ответе за своих детей
● Упавшего ребенка можно:
● Stop: остановить;
● Restart: перезапустить;
● Continue: оставить полу-лежачим;
● Escalate: передать обработку выше.
● Решение рекурсивно
● Есть хуки preStart, preRestart, postStop, etc.
40. Akka remoting/cluster
● Волшебный ActorRef: может указывать куда угодно
● Нет никакой разницы:
o Акторы в одной JVM;
o Акторы в разных JVM;
o Акторы на разных серверах;
o Акторы в нескольких DC, континентах и галактиках.
41. Akka remoting/cluster
● Волшебный ActorRef: может указывать куда угодно
● Набор полезных примитивов:
o Publish-subscribe;
o Singleton;
o Cluster state feed;
o Cluster-aware routers.
● Нет никакой разницы:
o Акторы в одной JVM;
o Акторы в разных JVM;
o Акторы на разных серверах;
o Акторы в нескольких DC, континентах и галактиках.
42. Akka remoting/cluster
● Волшебный ActorRef: может указывать куда угодно
● Набор полезных примитивов:
o Publish-subscribe;
o Singleton;
o Cluster state feed;
o Cluster-aware routers.
● Легко отстрелить ногу
● Нет никакой разницы:
o Акторы в одной JVM;
o Акторы в разных JVM;
o Акторы на разных серверах;
o Акторы в нескольких DC, континентах и галактиках.
43. Akka в бою: задача
● Кейс: классический web-crawling
o Поисковик по людям (как http://people.yandex.ru, только круче).
o Все просто на первый взгляд.
o Но становится сложно, когда возрастают объемы.
44. Akka в бою: задача
● Кейс: классический web-crawling
o Поисковик по людям (как http://people.yandex.ru, только круче).
o Все просто на первый взгляд.
o Но становится сложно, когда возрастают объемы.
● Проблемы:
o распределенная очередь;
o ненадежная сеть;
o ненадежные сервера;
o разные сценарии сбора для разных сайтов;
o невалидный HTML;
o невозможно парсить весь рунет
на одном сервере.
45. Статистика
● Три машины: 32Gb RAM, Linux
● 500 запросов/с на машину, поток 50мбит
● 30Тб данных в месяц
● в очереди ~300 млн. целей
● полный пересбор раз в два месяца
47. 0 AD
Прототип паука:
● был написан на С++ и libcurl;
● работал на одном сервере.
Наступили на грабли:
● Упёрлись в один сервер
48. 0 AD
Прототип паука:
● был написан на С++ и libcurl;
● работал на одном сервере.
Наступили на грабли:
● Упёрлись в один сервер
● Слали запросы синхронно:
o 2000 простаивающих потоков, ждущих данные из сети;
o 2k*8Mb = 16Gb памяти только на стек для потоков;
o Нельзя делать select из >1024 дескрипторов.
49. 0 AD
Прототип паука:
● был написан на С++ и libcurl;
● работал на одном сервере.
Наступили на грабли:
● Упёрлись в один сервер
● Слали запросы синхронно:
o 2000 простаивающих потоков, ждущих данные из сети;
o 2k*8Mb = 16Gb памяти только на стек для потоков;
o Нельзя делать select из >1024 дескрипторов.
● Сегфолты: падающий поток мог вынести всё:
o Coredump на 20Гб;
o полчаса чтобы посмотреть бектрейс.
50. 0 AD
Прототип паука:
● был написан на С++ и libcurl;
● работал на одном сервере.
Наступили на грабли:
● Упёрлись в один сервер
● Слали запросы синхронно:
o 2000 простаивающих потоков, ждущих данные из сети;
o 2k*8Mb = 16Gb памяти только на стек для потоков;
o Нельзя делать select из >1024 дескрипторов.
● Сегфолты: падающий поток мог вынести всё:
o Coredump на 20Гб;
o полчаса чтобы посмотреть бектрейс.
● Жизнь слишком коротка для С++
51. 2013
После хождения по граблям, поняли что хотим:
● асинхронное IO;
● масштабирование из коробки;
● сказать нет shared mutable data;
● восстановление после сбоев;
● легкость отладки и тестирования.
52. 2013
После хождения по граблям, поняли что хотим:
● асинхронное IO;
● масштабирование из коробки;
● сказать нет shared mutable data;
● восстановление после сбоев;
● легкость отладки и тестирования.
Варианты:
● Scala + Akka;
● Java + Akka;
● Erlang;
● boost: asio, phoenix, cppnetlib.
53. 2013
После хождения по граблям, поняли что хотим:
● асинхронное IO;
● масштабирование из коробки;
● сказать нет shared mutable data;
● восстановление после сбоев;
● легкость отладки и тестирования.
Варианты:
● Scala + Akka;
● Java + Akka;
● Erlang;
● boost: asio, phoenix, cppnetlib.
55. Работа с сетью
Несколько вариантов:
● spray.io
o написан на idiomatic Scala, свой DSL;
o Akka под капотом;
o немного для других вещей;
o spray-can сбоку на изоленте, многое не умеет;
o разработку штормит, в процессе слияния с akka-http.
56. Работа с сетью
Несколько вариантов:
● spray.io
o написан на idiomatic Scala, свой DSL;
o Akka под капотом;
o немного для других вещей;
o spray-can сбоку на изоленте, многое не умеет;
o разработку штормит, в процессе слияния с akka-http.
● Apache http-async-client
o Java;
o стабильный как мамонт;
o умеет вообще всё;
o модульный и расширяемый
(inb4 MyConnectionKeepAliveStrategyBuilderFactory);
o свои, ни с чем не совместимые Future, ThreadPool и т.д.
57. AHC
● Не такой уж и асинхронный:
o решили использовать общий с akka thread-pool;
o Java DNS lookup - синхронный и через UDP;
58. AHC
● Не такой уж и асинхронный:
o решили использовать общий с akka thread-pool;
o Java DNS lookup - синхронный и через UDP;
o UDP иногда теряется, это норма;
o потеря пакета - вечная блокировка потока в thread-pool;
o через два дня работы весь thread-pool заблокирован.
59. AHC
● Не такой уж и асинхронный:
o решили использовать общий с akka thread-pool;
o Java DNS lookup - синхронный и через UDP;
o UDP иногда теряется, это норма;
o потеря пакета - вечная блокировка потока в thread-pool;
o через два дня работы весь thread-pool заблокирован.
● Как жили дальше:
o раздельные thread-pool для akka и AHC;
o свой dns lookup, который умеет в таймауты;
o регулярное изучение thread dump’ов на предмет блокировок.
61. Одноразовые акторы
● Создать нового актора - дешево и быстро:
o ~300 байт памяти;
o можно создать хоть миллион.
● Одна подзадача - один актор:
o получил задачу;
o сделал её, послал результат и помер.
● Чистые иммутабельные акторы
62. Одноразовые акторы
● Создать нового актора - дешево и быстро:
o ~300 байт памяти;
o можно создать хоть миллион.
● Одна подзадача - один актор:
o получил задачу;
o сделал её, послал результат и помер.
● Чистые иммутабельные акторы
63. Одноразовые акторы
● Создать нового актора - дешево и быстро:
o ~300 байт памяти;
o можно создать хоть миллион.
асинхронный
коллбек!
Future[T]
● Одна подзадача - один актор:
o получил задачу;
o сделал её, послал результат и помер.
● Чистые иммутабельные акторы
65. Ask pattern
● Возможность что-то асинхронно спросить у актора
● Ответ - монада Future[T]
● Под капотом:
o создается временный актор, который ждет ответа;
o ответ заворачивается в результат Future.
66. Ask pattern
● Возможность что-то асинхронно спросить у актора
● Ответ - монада Future[T]
● Под капотом:
o создается временный актор, который ждет ответа;
o ответ заворачивается в результат Future.
67. Ask pattern
● Возможность что-то асинхронно спросить у актора
● Ответ - монада Future[T]
● Под капотом:
o создается временный актор, который ждет ответа;
o ответ заворачивается в результат Future.
68. Ask pattern
● Возможность что-то асинхронно спросить у актора
● Ответ - монада Future[T]
● Под капотом:
o создается временный актор, который ждет ответа;
o ответ заворачивается в результат Future.
порядок
вычисления
70. Akka ask puzzle
● Вылетел exception
● Что окажется в result?
1. Failure(e:UnsupportedOperationException).
2. “”
3. Failure(e:AskTimeoutException).
4. Failure(e:ClassCastException).
71. Akka ask puzzle
● Вылетел exception
● Что окажется в result?
1. Failure(e:UnsupportedOperationException).
2. “”
3. Failure(e:AskTimeoutException).
4. Failure(e:ClassCastException).
72. Akka ask puzzle
● Вылетел exception
● Что окажется в result?
1. Failure(e:UnsupportedOperationException).
2. “”
3. Failure(e:AskTimeoutException).
4. Failure(e:ClassCastException).
73. Akka ask puzzle
● Вылетел exception
● Что окажется в result?
1. Failure(e:UnsupportedOperationException).
2. “”
3. Failure(e:AskTimeoutException).
4. Failure(e:ClassCastException).
Временный актор
создается вне общей
иерархии
74. Мы и ask pattern
● Если уметь готовить аски, то жить можно
● Используем длинные цепочки асков:
Bot ScriptAction ScriptRunner
RequestExetutorThrottlerHttpClient
75. Мы и ask pattern
● Если уметь готовить аски, то жить можно
● Используем длинные цепочки асков:
Bot ScriptAction ScriptRunner
RequestExetutorThrottlerHttpClient
● Легкая декомпозиция задачи на части
● Каждую часть легко тестировать
● Есть overhead на создание временного актора
77. FSM, Конечные автоматы
● Можно и без них, но с ними удобнее
● Помогают в задачах, когда:
o актору нужно долго подниматься;
o есть четкие переходы между состояниями.
78. FSM, Конечные автоматы
● Можно и без них, но с ними удобнее
● Помогают в задачах, когда:
o актору нужно долго подниматься;
o есть четкие переходы между состояниями.
● Увлеклись:
o у бота 10 состояний;
o ~30 правил перехода;
o 500 строк лапши;
o тестировать почти невозможно.
79. FSM, Конечные автоматы
● Можно и без них, но с ними удобнее
● Помогают в задачах, когда:
o актору нужно долго подниматься;
o есть четкие переходы между состояниями.
● Увлеклись:
o у бота 10 состояний;
o ~30 правил перехода;
o 500 строк лапши;
o тестировать почти невозможно.
● Сейчас:
o у бота 2 состояния (просыпаюсь и активный) и 5 правил;
o вся логика вынесена в отдельные акторы;
есть и дочерние FSM.
81. Тестирование
● Синхронное через TestActorRef
o можно руками дернуть актора за receive();
o в самый раз для простой логики.
Два подхода к тестированию:
82. Тестирование
● Синхронное через TestActorRef
o можно руками дернуть актора за receive();
o в самый раз для простой логики.
● Асинхронное через akka.TestKit
o полный запуск системы;
o дополнительный синтаксис для assert-ов;
o можно подсовывать mock-акторов.
Два подхода к тестированию:
83. Логгинг
● Есть интеграция c slf4j
● log.debug(“foo”) - отправка сообщения логгеру
● MDC - message diagnostic context
84. Логгинг
● Есть интеграция c slf4j
● log.debug(“foo”) - отправка сообщения логгеру
● MDC - message diagnostic context
У нас:
● Свой логгер на основе akka.event.slf4j.Slf4jLogger
● Пишем логи в кассандру:
o 5-10Гб в сутки;
o разный time-to-live для DEBUG/INFO/WARN/ERROR;
o агрегация на лету при записи;
o простой web-gui, который рисует статистику.
89. “Динамическая” типизация
● Боль: несоответствие типов сообщений вылезает
наружу только в run-time
● Хочется строгой типизации
[1]: H.E. Jiansen: Typecasting actors, from Akka to TAkka
[2]: Akka 2.x Roadmap
90. “Динамическая” типизация
● Боль: несоответствие типов сообщений вылезает
наружу только в run-time
● Хочется строгой типизации
[1]: H.E. Jiansen: Typecasting actors, from Akka to TAkka
[2]: Akka 2.x Roadmap
91. “Динамическая” типизация
● Боль: несоответствие типов сообщений вылезает
наружу только в run-time
● Хочется строгой типизации
Старая проблема:
● TypedActor в Akka 2.0
● TAkka [1]
● “Gålbma”, Akka 3.0 [2]
[1]: H.E. Jiansen: Typecasting actors, from Akka to TAkka
[2]: Akka 2.x Roadmap
92. “Динамическая” типизация
● Боль: несоответствие типов сообщений вылезает
наружу только в run-time
● Хочется строгой типизации
Старая проблема:
● TypedActor в Akka 2.0
● TAkka [1]
● “Gålbma”, Akka 3.0 [2]
[1]: H.E. Jiansen: Typecasting actors, from Akka to TAkka
[2]: Akka 2.x Roadmap
У нас:
● Интеграционные тесты
● Акторы обычно умеют только
в один тип сообщений
94. Ошибки: Thread starvation
Что это:
● Блокировка потоков в thread-pool.
Откуда берутся:
● Thread.sleep(), Await.result() внутри актора;
● долгие вычисления;
● интеграция с легаси-кодом.
95. Ошибки: Thread starvation
Методы борьбы:
● ломать пальцы за Thread.sleep() внутри актора;
● отдельные dispatcher’ы;
● мониторинг стека вызовов и загруженности
потоков.
Что это:
● Блокировка потоков в thread-pool.
Откуда берутся:
● Thread.sleep(), Await.result() внутри актора;
● долгие вычисления;
● интеграция с легаси-кодом.
97. Ошибки: OutOfMemoryException
Причины:
● переполнение почтового ящика;
● слишком много акторов.
Что делать:
● мониторить загруженность почтового ящика;
● прореживать очередь сообщений;
● периодически изучать heap-dump и GC logs на
предмет утилизации памяти;
● следить за логическими утечками (замыкания).
98. В итоге
● прошли путь от akka 2.0 до 2.3.x
● один год в production
99. В итоге
● прошли путь от akka 2.0 до 2.3.x
● один год в production
● в начале приходится тяжело:
100. В итоге
● прошли путь от akka 2.0 до 2.3.x
● один год в production
● много скрытых граблей, но жить можно
● исключительно простой и выразительный
формализм
● удобно разрабатывать и тестировать
● в начале приходится тяжело:
101. Ссылки
● Typesafe activator [1]
● Coursera: Principles of reactive programming [2]
● Книги:
o Jamie Allen: Effective Akka, 2013;
o Derek Wyatt: Akka concurrency, 2013.
● Блоги:
o letitcrash.com [4]
[1]: https://typesafe.com/activator
[2]: https://www.coursera.org/course/reactive
[3]: https://letitcrash.com