Продолжаем публиковать видеоинтервью, взятые весной в онлайн-трансляции JPoint: в этот раз представляем разговор о перформансе со спикерами Алексеем Шипилёвым и Сергеем Куксенко. На предстоящем Joker Алексей снова выступит, а в онлайн-трансляции между докладами мы снова будем расспрашивать спикеров.
— Приветствую! Сегодня с нами перформансники Алексей Шипилёв из Red Hat и Сергей Куксенко из Oracle. Алексей уже выступил с кейноутом про перформанс, Сергею только предстоит рассказать про оптимизацию перформанса у HTTP/2 Client.
После выступления Алексея многие рассуждают о «зонах» работы над производительностью. А насколько это всё применимо к оптимизации производительности на системном уровне, которой занимается Сергей? То, о чём Алексей рассказывал в кейноуте — это применимо для стандартных Java-разработчиков или для того, что Сергей делает, тоже?
Алексей: Мне кажется, что это применимо вообще в широком смысле. Понятно, что есть некоторые границы применимости, и оно не всегда бывает так. Это, скорее, был такой типичный случай того, как всё обычно происходит. Мне кажется, что оно в таком виде есть на всех уровнях, оптимизируете ли вы производительность на прикладном уровне, на системном — на каком угодно. На системном уровне вы пишете те же самые алгоритмы, и у вас могут быть те же самые алгоритмические проблемы, которые могут быть и на прикладном уровне. Точно так же вы можете начать делать всякую дичь на любом уровне. Поэтому я не считаю это каким-то специальным знанием.
— А на системном уровне тоже начинают с говнокода?
Алексей: Да, я думаю, если вы почитаете исходники любого системообразующего проекта, будь это OpenJDK, GCC, LLVM, линуксячье ядро, вас ждёт много интересных открытий.
Сергей: В принципе, я с этим согласен, хотя в ряде случаев я считаю это разделение искусственным. В том числе и призыв переписывать говнокод для получения перформанса. Говнокод нужно переписывать, если он плохо работает. Если он работает функционально правильно и никак не мешает перформансу, пусть остаётся говнокодом, зачем тратить на него время и нервы. В остальных случаях, если у вас есть какая-то проблема с перформансом, то неважно — красная зона, зелёная, жёлтая, оранжевая, голубая — берём и переписываем. Не вижу здесь никаких проблем. Ну, и, опять же, мне кажется, что ценность перформанса преувеличена. Люди носятся с этим делом, как подростки носятся с сексом, но в реальности с этим гораздо проще.
Алексей: Все говорят, но мало кто делает.
Сергей: Оно должно работать, а всё остальное уже не так важно.
— В кейноуте Алексея было несколько спорных утверждений. Одно из них — отрицание тезиса «преждевременная оптимизация — корень всех зол», Алексей говорил «в чём же зло, если мы переписываем говнокод». Сергей, а как вы к этому тезису относитесь?
Алексей: Хочу заметить, что там два тезиса: оригинальный, Кнута, о том, что «преждевременная оптимизация — корень зла, примерно 99,7% всех оптимизаций делаются не там и не помогают производительности». В поп-культуре вторую часть отрезали и носятся только с первой, после чего игнорируют вполне себе нормальные изменения в коде, дешёвые с точки зрения реализации и поддерживаемости, которые на халяву увеличат производительность, под соусом того, что Кнут-де завещал, что преждевременная оптимизация — корень всего зла.
Сергей: Лично я не совсем согласен с этим тезисом, мне вообще немного не ясен смысл понятия преждевременной оптимизации.
— Это когда ты начинаешь оптимизировать то, что ещё не показало проблем с перформансом.
Сергей: Дело даже не в том, что преждевременная оптимизация делается не там, а в том, нужно ли заниматься перформансом в принципе. Проблема заключается в том, что люди начинают думать о перформансе, даже когда им это не нужно. У нас есть продукт, есть функционал. А перформанс? А что перформанс? «Петька, приборы?» Зачем нам вообще поднимать вопрос о перформансе, пока у нас не возникнет каких-то проблем? Если нас есть SLA, который требует столько-то реквестов в секунду для нашей системы, мы начинаем его смотреть и мерять, если нет — уже идут другие требования.
Алексей: Я с этим согласен. В начале моего кейноута тезис заключался в том, что перформанс, как правило, не является критерием успеха, он даже отсутствует в метриках успеха. Большая часть перформансной работы, которая нужна проектам, это такое sanity checking — не делать совсем уж глупых вещей, которые просто тратят ресурсы на всякую дрянь.
Сергей: Хочу добавить, что в некоторых компаниях, в том же Oracle, существуют выделенные перформансники. Формально, это ребята, которые не пишут код. Идеальная работа перформансника заключается примерно в следующем: приходят люди, говорят, что у них есть проект, нужно сделать перформанс. Ты, как перформансник, тратишь какое-то время: это может быть день, несколько недель, два месяца — не важно. После этого никаких изменений не делается, ставится галочка «с перформансом всё хорошо», и все расходятся.
— Вы оба — хардкорные спикеры, но после этого разговора, чувствую, на следующем JPoint нам следует ждать энтерпрайзных докладов, раз уж перформанс никому не нужен.
Алексей: Нет, ну, перформанс нам нужен.
— Главное, понимать, кому и когда он нужен.
Алексей: Просто экосистема очень большая, и даже если мы говорим, что перформанс нужен сотому проценту проектов, это означает, что в масштабах экосистемы речь идёт о десятках/сотнях проектов. Мы в этих проектах и работаем.
— Обычно ваши доклады не призваны становиться такой инструкцией, что после них ты пошёл пилить свой код в соответствии с заветами. Может, были какие-то случаи, когда люди подходили после JPoint или Joker и говорили: «Я послушал ваш доклад, вы там показали такие примеры, что я пришёл домой, запилил, и всё прям полетело, шикарно».
Сергей: Я не знаю. Какие бы доклады я ни делал, единственный посыл этих докладов — ребята, используйте свой мозг. И я не получал фидбэков о том, что кто-то стал свой мозг использовать. Наверное, потому что думают, что они и раньше его использовали. А мысль всё равно надо доносить.
Алексей: Мне кажется, проблема вот в чём: для нас многие вещи, которые мы делаем ежедневно, самоочевидны. В разговорах с разными людьми, которые приходят ко мне с тривиальными для меня проблемами, я показываю тривиальные способы решения, и я внезапно для себя понял, что вещи, которые мы знаем и считаем тривиальными, не такие уж и простые. Часть моей роли в докладах и в обзорном кейноуте, пожалуй, состоит в том, чтобы примерно показать, в какую сторону копать. Обычно у простого человека, который не занимался никогда производительностью, при столкновении с задачей, которая издалека похожа на перформанс, случается правоверный ужас, потому что он не знает, что делать. Когда ты ему просто показываешь, что можно посмотреть вот туда и туда, он говорит, что да, всё нормально, туда и начну копать. Мне приходили фидбэки, в которых говорилось именно об этом. Люди говорили, что они не понимали, как делать перформанс, и сейчас не до конца понимают, как его делать, но хотя бы понимают, что в одних компаниях делается вот так, в других продуктах — вот так, такие могут быть подходы, и на этом можно базировать собственные процессы, идеи и проработку. Одно дело говорить людям, чтобы они использовали мозг, а другое дело говорить: используйте мозг, а начать можно, кстати, вот с этого. Это, я считаю, более полезная, конструктивная парадигма общения с людьми.
Сергей: Полезная и конструктивная, но картинка возникает следующая: с самых первых докладов делалось так — «используйте свой мозг, но вот вам чек-лист», но при этом нельзя забывать следующее, что чек-лист чек-листом, но он не является догмой. После того, как вы разобрались с чек-листом, выкиньте его и используйте мозг.
Алексей: Понятно, что там в какой-то степени требуется изобретательность и творчество, но оно должно быть изначально чем-то засеяно. А откуда это засеивается? Многие вопросы, которые мне задают после докладов, состоят в следующем: какую книжку или статью прочитать, чтобы начать? Какой доклад послушать? То есть люди понимают, что это сложная задача, у неё нет однозначного ответа, её нужно прорабатывать. Проблема всегда заключается в том, что, когда ты нуб и заходишь со стороны в какую-нибудь область знаний, ты не понимаешь, где там вход, за какую ниточку тянуть, чтобы вытащить всю эту колбасу. Это не только с перформансом, это и с другими штуками. Мне кажется, что нужно давать людям подобную ниточку, за которую можно взяться, несмотря на то, что на другом конце может стоять чудовище, которое сожрёт этих людей. Ты им скажешь, что надо потянуть за хвост, а на самом деле ты потянешь за хвост дракона, который придёт и откусит тебе голову. И они тебе скажут: «Хорошо, что предупредил, мы будем тянуть вместе с кем-нибудь».
Сергей: Это можно о чём угодно так говорить. На самом деле, у перформанса нет никакой эксклюзивности. Это просто класс задач.
Алексей: Да, класс задач. К сожалению, я тут как-то думал, каким образом так получилось, что с функциональным тестированием и тем, как менеджить баги, как их приоритезировать и прочее, как их находить, какие бывают виды функционального тестирования — с этим человечество как-то худо-бедно разобралось. Это считается достаточно общим знанием. Перформанс — это ещё одна часть всей этой мозаики, и человечество постепенно идёт в эту сторону, начинает нарабатывать некий корпус общих знаний о том, как заниматься перформансом. Там нет ничего эксклюзивного. Особенность исторического момента состоит в том, что с функциональным тестированием мы разобрались, и с багами, с менеджментом проектов и так далее, а перформансу мы пока что учимся.
Сергей: Здесь есть ещё другая сторона, потому что функциональное тестирование так или иначе необходимо, а перформанс можно не делать. Это необязательная вещь, можно подождать, пока производители железа сделают что-нибудь более полезное и быстрое. Поэтому перформанс является опциональным, и люди не сильно стремятся накапливать какие-то шаблоны поведения в этой области. Шаблон «подождать» просто работает чаще.
Алексей: Но мы на конференциях рассчитываем не только на таких людей. Вернее, мы не рассчитываем, что именно такие люди тут в основном гнездятся. Мы разговариваем с аудиторией, которой как раз хочется заниматься перформансом, у них есть бизнес-цели по перформансу, они понимают, зачем им это нужно, но они не знают, с чего начать.
— К вопросу про ниточки и драконов: следя за различными Java-ресурсами, я вижу там 100500 разных статей, мануалов о том, как начать со Spring Boot, с функциональным тестированием, с чем-то ещё. Но почти не вижу статей о том, как начать с перформансом. Согласны ли вы, что со статьями и текстами какой-то дефицит?
Алексей: Я, скорее, согласен, в основном из-за того, что сказал Сергей, что, в принципе, это штука опциональная, поэтому она не считается частью общего знания. Когда я у себя в голове формулирую какой-нибудь перформансный пост, у меня всегда внутри сидит такой червячок и говорит: «Вот ты сейчас расскажешь людям что-нибудь про перформанс, а они подумают, что это какая-то обязательная штука». И это сильно останавливает. Это такая грань: рассказываешь что-то очень крутое, а потом люди идут и тут же начинают это внедрять. И ты думаешь: «Чёрт побери, ну зачем?» Брайан Гётц обычно заканчивает свои посты тем, что говорит: «Мы рассказали вам вот такую интересную вещь, но с вероятностью 99% это вам никогда не понадобится». Но это не означает, что ты можешь игнорировать тот один процент, которому это нужно. Поэтому на конференции и есть ценз на опытных программистов, среди них есть более существенная вероятность, что это нужно не 1%, а 5%, 10%, 20% и так далее. Тоже не всем, но существенно большему количеству людей.
— Наверное, можно в начало ставить Safe Harbour-слайд «доверяйте опытным людям, а может быть не доверяйте никому, может вам это и не надо». Последний вопрос связан с тем, что вы такие хардкорные системщики, ходите на JPoint. А вы вообще другие доклады слушаете? Было ли такое, что вы пришли на чей-то доклад, и он прям зашёл, был полезен и вы что-то новое для себя узнали?
Алексей: Во-первых, я в основном хожу на конференции, чтобы общаться с людьми, а не слушать доклады, поэтому не могу ничего по этому поводу сказать. А во-вторых, я всё равно видел основные доклады на слайдах и знаю, о чём там идёт речь. Думаю, гораздо полезнее, что мы просто ходим по коридорам и отвечаем на вопросы.
Сергей: В этом смысле, если тебе конкретно что-то интересно, и ты смог пролистать слайды другого спикера за 10 минут, лучше потратить оставшиеся 40 минут, поймав этого спикера в кулуарах и получив полезную информацию. Также мы на конференции не для того, чтобы получать какую-то информацию, а чтобы делиться тем, что у нас есть. Это задача первого приоритета.
— Всё равно же вы получаете какой-то фидбэк от людей, вы же здесь не с джунами общаетесь, а с людьми, у которых тоже хорошая экспертиза. Было ли такое, что в кулуарах что-то полезное узнавали для себя?
Алексей: Да. Когда общаешься с людьми, ты понимаешь, что им важно из того, что ты делаешь или пока не делаешь, но у тебя это в каких-то туду-листах, то есть каким-то образом выстраиваешь свою картинку приоритетов.
Сергей: В том числе им бывает важно то, что тебе нужно в туду-лист внести.
Алексей: Да. В принципе, проблема области нашей работы в том, что у нас-то работы всегда много. Вопрос в том, какая из этих задач важнее в нашей ограниченной жизни, что мы успеем сделать, а что — нет. Это для нас как раз ценно в конференции, что ко мне может подойти кто-то и сказать: «Чувак, не надо делать фичу А, потому что она нам не нужна. А вот если сделаешь фичу В, нам это очень сильно поможет». И Oracle, и Red Hat сильно заинтересованы в том, чтобы экосистема была живой. И это такая часть вливания ресурсов в экосистему, когда ты ходишь и как большой Ух прислушиваешься к тому, что происходит.
— Друзья, спасибо большое!
Алексей ШипилёвРаботает над производительностью Java вот уже почти 10 лет. Успел позаниматься производительностью Apache Harmony в Intel, затем перешёл в Sun Microsystems, а потом и в Oracle, где работал над производительностью Sun/Oracle JDK, в том числе производительностью JVM, библиотек классов, фреймворков и приложений. На данный момент трудится в Red Hat. Являлся техническим представителем Oracle в Standard Performance Evaluation Corporation (SPEC), занятой разработкой и поддержкой промышленных бенчмарков. В данный момент серьёзную часть времени тратит на Java Microbenchmark Harness, инструмент для измерения производительности Java-кода.
Сергей КуксенкоJava Performance Engineer. Работает с Java начиная с версии 1.0. За это время успел поучаствовать в разработке мобильных, клиентских, серверных приложений, а также виртуальных машин. Производительностью Java занимается c 2005 года: сначала работал в Intel над Apache Harmony, а в данный момент в Oracle занимается производительностью OracleJDK/OpenJDK (его 3-я JVM). @kuksenk0
