Хабрахабр

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

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

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

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

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

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

Тем не менее, у 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…

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

Это человек, выпустивший почти две сотни выпусков подкаста Разбор Полётов, автор кучи докладов, текстов, постов и даже книги «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

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

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

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

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

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

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

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

План доклада

  • Введение: почему нам нужна многопоточность
  • Подходы к построению алгоритмов
    • Грубая блокировка
    • Тонкая блокировка
    • Неблокирующая синхронизация
    • Все три вида иллюстрируются на задаче-примере про игрушечный банк
  • Многопоточность — это сложно. Что делать?
    • Транзакции в идеальном мире. Просто пиши 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 на графиках

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

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

План доклада

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

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

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

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

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

Роман (elizarov) — в прошлом разработчик высокопроизводительного трейдингового софта, а сейчас — тимлид в библиотеках Kotlin. Только ленивый не знает сейчас о 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, ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть