Лучшие доклады JPoint 2018: Java-JVM и её перформанс, Kotlin, Spring, Docker

в 10:37, , рубрики: devops, java, jpoint2018, kotlin, Блог компании JUG.ru Group, высокая производительность

Мы уже выложили на YouTube видеозаписи докладов JPoint 2018 и специально для хаба Java на Хабре сделали традиционную подборку самых лучших из них по мнению посетителей конференции.

Как обычно, наверху «младшие» доклады, в конце — с самым высоким рейтингом. Конечно, это не значит, что один доклад намного хуже другого: если изменить методику расчета, места могут легко поменяться. В реальности, мы её и изменили, теперь используется «soft quorum» вариант рейтинга, учитывающий количество присутствовавших на докладе участников. Этот подходит имеет свои минусы (например, на кейноут приходит больше людей, чем на обычный доклад, просто потому что у аудитории нет выбора), но в целом даёт более качественную картину произошедшего.

Под катом — и видеозаписи лучших докладов, и ссылки на их презентации, и короткие описания, и ссылка на полный плейлист.

Лучшие доклады JPoint 2018: Java-JVM и её перформанс, Kotlin, Spring, Docker - 1

Полный плейлист

Полный плейлист со всеми видео, о которых пойдет речь ниже, доступен по ссылке.

10. Linux container performance tools for JVM applications

Скачать слайды

Контейнерная революция захлестнула всех — не обошелся без этого и мир Java. Тем не менее, у Java с этим всегда были и есть некие проблемы и особенности, о которых и пойдет речь в докладе Саши Гольдштейна.

Саша — серийный создатель перформансного хардкора. В прошлом году на JPoint он сделал отличный доклад про использование Berkeley Packet Filter для JVM (отчаянно рекомендую посмотреть запись на YouTube), и это был только вопрос времени, когда он доберётся до подробного разбора контейнеризации. Мир уходит в облака и докеры, что в свою очередь приносит нам множество новых проблем. Как вы могли заметить, большинство низкоуровневых систем отладки и профилирования после их применения к контейнерам обрастают разными особенностями и косяками. Саша катком прошелся по основным сценариям (загрузке CPU, отзывчивости IO, доступу до расшаренных баз и т.п.) сквозь призму использования современных инструментов на платформе GNU/Linux, включая BCC и perf.

Эта специфика нужна далеко не всем. Это одна из причин, почему доклад оказался лишь на десятом месте — на нем присутствовало около двух сотен человек (сравните с более чем тысячью у Толкачева и Борисова), а наш алгоритм вычисления рейтинга очень чувствителен к размеру аудитории.

Для тех же, кто так или иначе связан с контейнерами, этот доклад нужно обязательно посмотреть. Сэкономит кучу времени на самостоятельный поиск всех подробностей методом полного перебора бесчисленного количества утилит и способов их использования.

Еще хочется отметить, что доклад Саши из всего топ-10 — чуть ли не самый плотный по количеству практической информации на единицу времени. Почти с каждого слайда можно скопипастить себе какие-нибудь полезные вещи. Чтобы не заниматься подробным пересказом, покажу только поверхностную структуру изложения:

План доклада

  • Как устроены контейнеры?
    • Control groups: CPU, memory, block I/O;
    • Namespaces: pid namespace, mount namespace, network namespace;
  • Разница между возникающими проблемами:
    • На хосте;
    • В контейнере;
    • Примеры проблем с решениями:
      • Подключение к JVM?
      • Данные о перформансе JVM?
    • Демо JVM-инструментов на хосте;
  • Инструменты для получения информации о ресурсах:
    • sidecar для мониторинга;
    • docker stats;
    • systemd-cgtop;
    • htop + cgroup ID;
    • nsenter или docker exec;
    • Демо мониторинга ресурсов контейнера;
  • Профилирование CPU-контейнеров:
    • perf на хосте: -G, symbol mapping, PID mapping, sharing perf map (perf-map-agent);
    • Демка с флеймграфами; оос;
    • perf в контейнере в непривилегированном режиме;
    • honest-profiler, async-profiler, perf vs async-profiler;
    • Демка async-profiler;
    • BCC — инструмент для профилирования (само решает рядо проблем, но работает только на Linux 4.9+);
    • Throttling;
  • Другие способы мониторинга:
    • cAdvisor, SysDig, New Relic, DataDog…

9. Один раз в год сады цветут: разбор семантики «exactly-once» Apache Kafka

Скачать слайды

Виктор Гамов имеет совершенно нечестное преимущество перед остальными докладчиками. Это человек, выпустивший почти две сотни выпусков подкаста Разбор Полётов, автор кучи докладов, текстов, постов и даже книги «Enterprise Web Development» издательства O'Reilly. Само присутствие Гамова делает что угодно лучше. Уверен, он мог бы с той же интонацией рассказывать не про Кафку, а про произрастание герани на подоконнике, и это всё еще было бы увлекательно.

Здесь же у нас особый случай: изначально холиворная тема про семантику «exactly once». Кафку бросились использовать все подряд в необычайных масштабах, что потребовало переработки традиционной семантики доставки сообщений. Кафке в рот палец не клади — они переобулись на ходу под правильный протокол и формат сообщений и сделали все что нужно. На протяжении доклада Виктор рассказывает, как там это устроено внутри и на что влияет.

Две новости, хорошая и плохая. Хорошая: в Кафке всё настраивается. Плохая: в Кафке всё настраивается. Чтобы жить с этим, нужно понимать, как это работает и куда лезть своими грязными руками.

От Виктора можно было бы ожидать какого-то смузи, но тут получился отчаянный хардкор, и план примерно такой:

План доклада

  • Введение в Кафку:
    • Топики
    • Партиции
    • Логи и оффсеты
    • Реплики и лидеры
    • Клиенты: продюсеры и консюмеры
  • Продюсер
    • Как работает на примерах
    • Протокол продюсера
  • Консюмер
    • Как работает на примерах
    • Протокол консюмера
  • Модель обработки
    • Прочитали, посчитали, записали
    • Виды сбоев (все сломалось, зомби)
  • Семантика обработки
    • At-least-once, at-most-once, exactly-once
  • Cемантика «exactly once»
    • С примерами
    • Слабости
      • небезопасные повторы
      • неатомарная запись со смещением
      • зомби
  • Чиним первую слабость: идемпотентный продюсер
  • Чиним вторую слабость:
    • Снэпшоты Чэнди-Лэмпорта
      • Принцип
      • Как жить со сбоями?
        • Hard: сбой во время обработки
        • Soft: сбой до или во время снятия снапшота
    • Транзакции в Кафке
      • Два типа маркеров (COMMIT, ABORT)
      • Атомарная запись на множество партиций (Включая !_consumer_offsets)
  • Чиним третью слабость: zombie fencing
  • Изоляция чтения у консюмера
  • end-to-end eos
    • Kafka Connect Source
    • Kafka Streams
    • Kafka Connect Sink

8. Боремся с "Russian Hackers" с помощью Kafka Streams и Firehose API

Скачать слайды

Опять Кафка! Опять Гамов! Да ещё и с Барухом Садогурским (jbaruch) теперь. Тем не менее, этот доклад — не смузи, а вполне конкретная практическая штука о том, как на платформе Bintray (богом которой является Барух) с помощью Apache Kafka (за которую отвечает Виктор) и Firehose анализировать поведенческие паттерны, обрабатывать большие объемы данных.

Если у предыдущего доклада про внутренности Кафки было 245 слайдов, то у этого их всего 17. Это потому, что его нужно смотреть! Это в первую очередь живой диалог между ведущими и живые демки. Не задерживаемся, открываем видосик и смотрим.

7. Аппаратная транзакционная память в Java

Скачать слайды

Никита Коваль (ndkoval) — исследователь в JetBrains в команде Kotlin и PhD студент в IST Austria (на момент доклада он был в Devexperts). Его доклад сильно контрастирует с "русскими хакерами", потому что это не легкое развлекательное чтиво, а рассказ про сложные внутренности VM. Если взглянуть на слайды, можно обнаружить 150 листов, значительная часть которых — код.

Если вы были на JBreak в начале 2018 года, то могли застать рассказ Никиты о совершенно других вещах — о написании быстрой многопоточной хэш-таблицы с использованием мощи современных многоядерных архитектур и специальных алгоритмов. Согласитесь, у Никиты есть стиль. Мне сразу вспоминается Шипилёв.

В этот раз речь пойдёт про транзакционную память, которая понемногу появляется в современных процессорах, но которую пока непонятно как использовать обычному человеку из JVM-мира. Вне JVM, конечно, все проще. Но представь себе, как ты говоришь обычному Spring веб-разработчику: "Да просто редактируешь vmstructs, наваливаешь своих интринсиков, пересобираешь OpenJDK и готово!" А он такой: "Ну конечно, каждый день так делаю!". Никита как раз очень внятно рассказывает про способы использования, какие оптимизации уже есть в OpenJDK и как выполнять транзакции напрямую из Java-кода.

План доклада

  • Введение: почему нам нужна многопоточность
  • Подходы к построению алгоритмов
    • Грубая блокировка
    • Тонкая блокировка
    • Неблокирующая синхронизация
    • Все три вида иллюстрируются на задаче-примере про игрушечный банк
  • Многопоточность — это сложно. Что делать?
    • Транзакции в идеальном мире. Просто пиши atomic!
    • Откуда взять atomic:
      • Software Transactional Memory (STM). Scala STM, NOrec, корутины.
      • Hardware Transactional Memory (HTM). Haswell, Power 8.
      • Hybrid Transactional Memory
    • Intel RTM на примерах
      • XBEGIN, XEND, XABORT, XTEST
      • Intel RTM + Java
        • Lock elision
        • java.util.concurrent.RTMSupport
      • Intrinsics: interpreter, C1, C2
      • Coarse-grained / Lock-free + RTMSupport на графиках

6. Профилируем с точностью до микросекунд и инструкций процессора

Скачать слайды

Сергей Мельников из Райффайзенбанка привез нам второй доклад по профилированию. Интересно, что до того, как заняться low-latency кодом на Java, он работал в Intel инженером по производительности компиляторов для языков C/C++/FORTRAN. В этом докладе тоже есть perf! :-) Ещё там про аппаратные особенности процессоров и технологии Intel Processor Trace, которая позволяет сделать следующий шаг в точности профилирования и реконструировать выполнение участка программы. Таких докладов довольно мало (например, можно найти доклад Andi Kleen на Tracing Summit 2015), они обычно оставляют море вопросов и не блещут практичностью применительно к Java. Здесь же у нас не просто есть человек, побывавший в обоих мирах (и Intel, и Java в банке), но еще и умеющий понятно объяснять сложные темы.

План доклада

  • Что это и зачем нужно
    • Предметная область — low latency приложения
    • Пример Московской биржи
  • Выбираем профилировщик
    • Как профилировать? Сэмплирующие и инструментирующие профилировщики
    • async-profiler
  • Учим профилировщик собирать подробный профиль
    • Как запускать perf
    • Как смотреть в профиль, в call stack
    • perf-map-agent, sysctl, dmesg…
  • Используем события PMU/PEBS в perf
  • Intel Processor Trace – что это такое и как профилировать Java
    • Требования: пакеты, железо, операционная система
    • Как запускать на Skylake-X (Xeon и i9)

5. VMStructs: зачем приложению знать о внутренностях JVM

Скачать слайды

Андрей (apangin) — это человек, раз за разом собирающий самые глубокие и мощные доклады. На прошлом Joker у него собралось чуть меньше тысячи человек — это рекорд по объему аудитории на обычном докладе, не являющимся кейноутом. В этом ему помогает десятилетний опыт работы над виртуальными машинами и умение объяснять технический хардкор так, чтобы его можно было повторить на практике.

Многим не совсем понятно, зачем копаться в виртуальной машине, если у тебя обычное приложение на томкате, с базой данных и все как положено. В этом докладе имеется хорошая аргументация на уровне "как понять, какой запрос потянет много данных?" Если попробовать проинструментировать код с помощью JMX, то с перформансом начинает твориться что-то странное. Во-первых, можно понять, почему так происходит, во-вторых — что с этим можно сделать. На мой взгляд, этот доклад ценен не столько набором инструментов (хотя там и есть немного про helfy), сколько демонстрацией правильного майндсета разработчика OpenJDK и того, как себя надо вести в сложных ситуациях. Проговаривается наличие и объясняется смысл конкретных вещей вроде TLAB, Code Cache, Constant Pool и т.п.

4. Корутины в Kotlin

Скачать слайды

Только ленивый не знает сейчас о Kotlin, а ты, читатель, раз дочитал до четвертого пункта — явно не из ленивых. Роман (elizarov) — в прошлом разработчик высокопроизводительного трейдингового софта, а сейчас — тимлид в библиотеках Kotlin. Мы уже делали с Ромой интервью про корутины, и его, возможно, стоит перечитать до или после просмотра доклада. Корутины — очень старая концепция, еще со времен Симулы, но далеко не все мэйнстримные языки их поддерживают, в Java они появятся нескоро. А вот в Kotlin они уже есть в стабильной версии.

Этот доклад отвечает на все актуальные вопросы про корутины, то есть на все актуальные вопросы современности вообще :-)

План доклада

  • Общая картина развития языков
  • Асинхронное программирование с коллбэками
  • Futures/Promises/Rx
  • Корутины в Kotlin
    • regular loops, exception handling, higher-order functions
    • custom higher-order functions
    • все выглядит как в блокирующем коде!
  • Как это работает?
    • suspending functions, code with suspension points
  • Интеграции
    • Retrofit async
    • Коллбэки и континуации (call/cc из Scheme!)
    • contlinx-coroutines-core
      • jdk, guava, nio, reactor, rx1, rx2
  • Как запускать корутины?
  • async / await
    • Почему в Kotlin нет ключевого слова await?
    • Concurrency — это сложно. Нужно делать это в явном виде.
    • Подход Kotlin к async
  • Концепция корутин: очень легкие треды
  • Интероп с Java
  • Синхронные корутины — generate/yield
    • Пример с числами Фибоначчи
  • Communicating Sequential Processes (CSP)
  • Library vs Language
    • Ядро языка должно быть небольшим!
    • Keywords: async/await, generate/yield
    • Modifiers: suspend
    • kotlinx-coroutines: launch, async, runBlocking, future, delay, Job, Deferred, ...

3. На плечах гигантов: языки, у которых учился Kotlin

Скачать слайды

Доклад про Kotlin от одного из создателей языка — что еще нужно для счастья? Суть и структура изложения совершенно не такая, как у предыдущего доклада Елизарова. Роман рассказывал про конкретные вещи — что, как и почему в дизайне корутин, и как это использовать, и это нужно мне для улучшения скилла программирования на Kotlin. Здесь же Андрей (abreslav) рассказывает вещи, которые улучшают эрудицию вообще по жизни и дают понимание своего места в мире. Если вы своими глазами видели все эти языки — Java, C#, Scala, Groovy, Python, Gosu — это еще интересней, потому что появляется повод для дискуссии (посетители конференции, вероятно, могли воспользоваться случаем и действительно обсудить свое понимание вещей вживую в дискуссионной зоне). Это такое «семь языков за семь недель», но только за один час.

Кстати, недавно мы делали с Андреем отдельное интервью, но оно не только про Kotlin, а про множество разных вещей.

2. Приключения Сеньора Холмса и Джуниора Ватсона в мире разработки ПО

Скачать слайды

Делать доклады, в которых участвует более одного докладчика — это необычайно сложно. Зачастую это выглядит так: половину времени один из них стоит на сцене и скучает, и выглядит это весьма уныло. Что можно сказать про совместное выступление Баруха Садогурского и Евгения Борисова (EvgenyBorisov) — оно, напротив, сделано великолепно, это произведение искусства. Звезды сошлись в правильном порядке, и на сцене оказались два топовых спикера с огромным опытом и практикой ведения парных докладов с целью обсудить интересную им обоим тему. Почему я так это подчеркиваю — обычно зрители понятия не имеют, чего стоит создание такого представления, и воспринимают всё как должное.

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

Это не доклад-справочник, а доклад-шоу, его нужно смотреть. В нем Холмс и Ватсон раскроют несколько загадок, с которыми вы сталкивались, сталкиваетесь или будете сталкиваться при каждодневной разработке. Кишок сборщиков мусора и байткода не будет, зато будут инструменты, библиотеки и фреймворки, которые озадачивают рядовых разработчиков в каждодневной рутине, приводят к простою, профукиванию дедлайнов и затяжным депрессиям. Практически, в этом докладе Шерлок и Ватсон спасают ваш лоб от фейспалмов и граблей, на которые кто-то уже наступал.

Поэтому краткого содержания здесь опять не будет — просто запускайте видео и смотрите.

1. Boot yourself, Spring is coming

Скачать слайды

Барух + Гамов, Барух + Борисов, кого не хватает среди авторов популярных парных докладов? Правильно, Борисов + Толкачев (tolkkv). Еще один крутейший доклад, который, не являясь кейноутом, собрал рекордное количество участников — больше тысячи. Материала оказалось настолько много, и он такой интересный, что на него выделили целых два слота в программе конференции — а вам на YouTube придется, соответственно, отсмотреть целых два видео.

Много лет назад Java-программисты пользовались «new» для создания сервисов. Они проделывали огромное количество ручных действий и смешивали конфигурацию с бизнес-логикой. Они даже использовали техники copy-paste. Было написано много строк убогого кода, который временами даже работал.

Потом появился Spring. С ним многое изменилось… Мы получили много «магии» из волшебного цилиндра Spring, и наш код стал более чистым, простым и поддерживаемым.

И вот появился Spring Boot. С одной стороны, он решает тысячи ранее существовавших проблем: конфликты версий, задачи конфигурации, работа с инфраструктурными бинами, проблему настройки окружения и, конечно же, запуск или деплой приложения, включая сборку jar/war-архивов. С другой стороны, Spring Boot добавил в наш волшебный цилиндр еще больше магии. В результате имеют место быть два сценария:

  • Всё прекрасно работает, хотя никто не знает, как.
  • Ничего не работает, и никто не знает, почему.

Этот доклад раскрывает основные секреты магии Spring Boot. Вы осознаете основные принципы и конвенции, по которым работают типичные Spring Boot-приложения. Задача Кирилла и Евгения, чтобы вся магия из цилиндра превратилась для вас в куда более прозрачный процесс и вы смогли не только получать удовольствие, когда всё работает, но и понимали суть возникающих проблем и могли решить их без привлечения скорой помощи и других служб, доступных по срочным вызовам.

Заключение

Мне понадобилось несколько дней для того, чтобы отсмотреть все видео из списка. Это было непросто, но ясно видно, что это того стоило. В реальности на конференции было куда больше докладов, и просмотр лучшей десятки из них — хорошее начало для куда более масштабного пути. Если будете тоже смотреть эти доклады — не поленитесь написать свои отзывы в комментариях на Хабре!

А тем временем уже можно приобретать билеты на следующий JPoint. Он пройдет 5-6 апреля 2019 в Конгресс-центре ЦМТ. До первого января все ещё есть возможность приобрести билеты по низким ценам!

Автор: Олег Чирухин

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js