Несмотря на огромное количество материалов по теме оптимизации монолита, часто хочется убежать от глубоко изучения вопроса и попробовать угадать, как сделать приложение быстрей или компактней. Хорошая новость: принцип Парето работает и здесь. На конференции RubyRussia 28 сентября Юлиан Покровский расскажет о необходимых приемах. А пара тизеров будет в этом интервью Юлиана с Григорием Петровым.
Чем ты занимаешься в мире IT, Ruby, твои интересы, экспертиза?
Я работаю в Купибилете. В проекте я писал на Ruby и на Rust бекэнд для поиска, бронирования и покупки авиабилетов. Меня интересует широкий спектр того, что происходит в IT: от компиляторов до распределенных систем. Не очень интересуюсь машинным обучением и фронтендом, но может когда-нибудь доберусь и туда.
Расскажи, о чем твой доклад?
Я расскажу о нашем опыте оптимизации 8-летнего монолита и покажу, что это очень просто и выгодно для всех. И есть возможность выделить для этого время в спринте. Получить прирост производительности можно разобравшись всего с несколькими простыми приемами и инструментами, которые не требуют Rails и подходят не только для веб-приложения. Расскажу о тех материалах, которыми мы руководствовались, когда решали свои проблемы. Посмотрим на stackprof, rbspy, heapy, а также почему тривиальные изменения настроек операционной системы, смена аллокатора, могут принести невероятную пользу. И почему плохо применять советы из интернета не проводя замеры на своем приложении.
Есть такая городская легенда, что если сравнивать языки большой четверки (Ruby, Python, JavaScript и PHP), то на первом месте у нас JS, потому что там await и jit, на втором PHP, потом Python, а Ruby занимает почетное 4-е место.Что скажешь, так ли это?
Я не склонен отрицать то, что Ruby на многих бенчмарках показывает себя не с лучшей стороны. Но однозначно не правильно говорить, что в любой ситуации он будет на последнем месте. Если взглянуть шире, то Ruby — это некий языковой стандарт. Мы можем говорить о TruffleRuby, о JRuby, о MRI, о вопросах производительности. Это очень индивидуальные вещи. Все зависит от того, как вы написали код и что вы хотели получить. В каких-то случаях Ruby будет быстрее всех, в каких-то Python, недаром же он популярен в data science, иногда JavaScript окажется наиболее быстрым.
Насколько сейчас экосистема Ruby предлагает быстрые, нативные способы решения популярных задач?
Я могу трактовать вопрос по-разному. Можно сказать о том, как сейчас в Ruby обстоят дела с С-экстеншенами. Если сузить вопрос до этого, то все мы знаем: OJ для сериализации JSON, PostgreSQL Driver, Ruby Driver for MySQL и многие другие вещи написаны на С. Вопрос в том, насколько для меня лично это хорошо или плохо. Для того чтобы jit компиляторы, которые, возможно, являются будущим Ruby, хорошо оптимизировали код, нам нужно больше писать на Ruby и меньше обращаться к экстеншенам. Чтобы сам компилятор мог делать это. TruffleRuby подходит к этому вопросу по-другому. Насколько я помню, он позволяет делать оптимизацию между разными языками, поэтому называется polyglot vm. Опять же, насколько успешно он это делает, я сказать не готов. И сам TruffleRuby — пока достаточно молодой проект.
Какие подвижки в мире Ruby сейчас есть для асинхронного программирования?
На мой взгляд, за последнее время массового движения в сторону асинхронного Ruby не произошло. Есть какие-то отдельные проекты: и проверенная EventMachine, и проект Сэма Уильямса, async, точнее целая группа проектов, в которой на основе nio4r делается новая реализация асинхронности, более простая, чем EventMachine или Celluloid. Но в целом история, хоть и не стоит на месте, скорее ходит по небольшому кругу. И за его пределы пока ничего не вышло. Посмотрим, что будет дальше.
Я по-прежнему вижу много использования concurrent-ruby на основе потоков. Это не такой плохой вариант для языка с умеренно производительным рантаймом — использовать потоки, которые освобождаю GVL (глобальный лок) и позволяют делать параллельные HTTP запросы или какие-то другие I/O операции одновременно. Может быть, файберы в будущем будут более популярны. Они сейчас легли в основу библиотеки из группы dry — dry-effects. Это как раз позволяет делать какие-то параллельные операции на основе файберов. Не синхронно, но и не совсем асинхронно — уже наполовину асинхронно.
На конференцию прилетает Мацумото-сан, автор Ruby. Как ты думаешь, что тебе было бы интересно с ним обсудить за чашкой кофе или бокалом саке на афтепати?
Я уже виделся с Мацумото в Москве в 2016 году. Я помню, он тогда сказал что если конференция продолжит называться RailsClub он больше не приедет.
Да, и ее переименовали в RubyRussia, это более широкое название. И он снова у нас в гостях.
Я тогда думал, кто победит, он или RailsClub. Победил Мацумото. Я бы спросил, как ему удалось так поставить вопрос, что переименовали самый большой ивент по Ruby в России.
Я думаю, у тебя будут все возможности задать этот вопрос лично. Какое ты видишь будущее у Ruby? Что тебе не хватает в языке, экосистеме?
Предсказание судьбы языка программирования — дело неблагодарное, потому что пока никто не угадал, как будут развиваться события ни для одного языка. Я могу ошибаться, но Ruby сейчас не самый популярный выбор для новых проектов. Многие слышали «Ruby мертв, а Rails устарели»: медленно, не асинхронно, не параллелится и у него в целом куча проблем. Влияет ли это на количество новых проектов на Ruby? На мой взгляд — однозначно да. Их становится меньше и будет становиться еще меньше. Но старые проекты остаются. На мой взгляд, в таком ключе Ruby нужны инструменты для поддержки сложных, массивных приложений. В таких ситуациях неплохо взглянуть на такие дополнения, как система типов. Многие предпочитают поддерживать большие приложения и развивать их, как мы видим на примере JavaScript с Flow и TypeScript, в сторону типизации, которая немного упрощает рефакторинг и контроль за ситуацией в сложном проекте. Возможно, нужно делать более богатую экосистему библиотек, которую нужно использовать независимо, как, например, dry-rb. Где человек может выбрать, что ему нужно для валидации, что для построения эффектов в какой-то подсистеме. Возможно, ему нужны контейнеры внедрения зависимостей, которые решают определенные проблемы. Экосистема должна двигаться в эту сторону. В сторону энтерпрайз разработки и поддержки больших и сложных систем.
Обсудим на RubyRussia!
Приходите и вы, регистрация еще открыта.
Будут не только доклады, но и стенды классных компаний:
Организатор — Evrone
Генеральный партнер — Toptal
Золотой партнер — Gett
Серебряные партнеры — Валарм, JetBrains, Bookmate и Cashwagon
Бронзовый партнер — InSales
Чем ты занимаешься в мире IT, Ruby, твои интересы, экспертиза?
Я работаю в Купибилете. В проекте я писал на Ruby и на Rust бекэнд для поиска, бронирования и покупки авиабилетов. Меня интересует широкий спектр того, что происходит в IT: от компиляторов до распределенных систем. Не очень интересуюсь машинным обучением и фронтендом, но может когда-нибудь доберусь и туда.
Расскажи, о чем твой доклад?
Я расскажу о нашем опыте оптимизации 8-летнего монолита и покажу, что это очень просто и выгодно для всех. И есть возможность выделить для этого время в спринте. Получить прирост производительности можно разобравшись всего с несколькими простыми приемами и инструментами, которые не требуют Rails и подходят не только для веб-приложения. Расскажу о тех материалах, которыми мы руководствовались, когда решали свои проблемы. Посмотрим на stackprof, rbspy, heapy, а также почему тривиальные изменения настроек операционной системы, смена аллокатора, могут принести невероятную пользу. И почему плохо применять советы из интернета не проводя замеры на своем приложении.
Есть такая городская легенда, что если сравнивать языки большой четверки (Ruby, Python, JavaScript и PHP), то на первом месте у нас JS, потому что там await и jit, на втором PHP, потом Python, а Ruby занимает почетное 4-е место.Что скажешь, так ли это?
Я не склонен отрицать то, что Ruby на многих бенчмарках показывает себя не с лучшей стороны. Но однозначно не правильно говорить, что в любой ситуации он будет на последнем месте. Если взглянуть шире, то Ruby — это некий языковой стандарт. Мы можем говорить о TruffleRuby, о JRuby, о MRI, о вопросах производительности. Это очень индивидуальные вещи. Все зависит от того, как вы написали код и что вы хотели получить. В каких-то случаях Ruby будет быстрее всех, в каких-то Python, недаром же он популярен в data science, иногда JavaScript окажется наиболее быстрым.
Насколько сейчас экосистема Ruby предлагает быстрые, нативные способы решения популярных задач?
Я могу трактовать вопрос по-разному. Можно сказать о том, как сейчас в Ruby обстоят дела с С-экстеншенами. Если сузить вопрос до этого, то все мы знаем: OJ для сериализации JSON, PostgreSQL Driver, Ruby Driver for MySQL и многие другие вещи написаны на С. Вопрос в том, насколько для меня лично это хорошо или плохо. Для того чтобы jit компиляторы, которые, возможно, являются будущим Ruby, хорошо оптимизировали код, нам нужно больше писать на Ruby и меньше обращаться к экстеншенам. Чтобы сам компилятор мог делать это. TruffleRuby подходит к этому вопросу по-другому. Насколько я помню, он позволяет делать оптимизацию между разными языками, поэтому называется polyglot vm. Опять же, насколько успешно он это делает, я сказать не готов. И сам TruffleRuby — пока достаточно молодой проект.
Какие подвижки в мире Ruby сейчас есть для асинхронного программирования?
На мой взгляд, за последнее время массового движения в сторону асинхронного Ruby не произошло. Есть какие-то отдельные проекты: и проверенная EventMachine, и проект Сэма Уильямса, async, точнее целая группа проектов, в которой на основе nio4r делается новая реализация асинхронности, более простая, чем EventMachine или Celluloid. Но в целом история, хоть и не стоит на месте, скорее ходит по небольшому кругу. И за его пределы пока ничего не вышло. Посмотрим, что будет дальше.
Я по-прежнему вижу много использования concurrent-ruby на основе потоков. Это не такой плохой вариант для языка с умеренно производительным рантаймом — использовать потоки, которые освобождаю GVL (глобальный лок) и позволяют делать параллельные HTTP запросы или какие-то другие I/O операции одновременно. Может быть, файберы в будущем будут более популярны. Они сейчас легли в основу библиотеки из группы dry — dry-effects. Это как раз позволяет делать какие-то параллельные операции на основе файберов. Не синхронно, но и не совсем асинхронно — уже наполовину асинхронно.
На конференцию прилетает Мацумото-сан, автор Ruby. Как ты думаешь, что тебе было бы интересно с ним обсудить за чашкой кофе или бокалом саке на афтепати?
Я уже виделся с Мацумото в Москве в 2016 году. Я помню, он тогда сказал что если конференция продолжит называться RailsClub он больше не приедет.
Да, и ее переименовали в RubyRussia, это более широкое название. И он снова у нас в гостях.
Я тогда думал, кто победит, он или RailsClub. Победил Мацумото. Я бы спросил, как ему удалось так поставить вопрос, что переименовали самый большой ивент по Ruby в России.
Я думаю, у тебя будут все возможности задать этот вопрос лично. Какое ты видишь будущее у Ruby? Что тебе не хватает в языке, экосистеме?
Предсказание судьбы языка программирования — дело неблагодарное, потому что пока никто не угадал, как будут развиваться события ни для одного языка. Я могу ошибаться, но Ruby сейчас не самый популярный выбор для новых проектов. Многие слышали «Ruby мертв, а Rails устарели»: медленно, не асинхронно, не параллелится и у него в целом куча проблем. Влияет ли это на количество новых проектов на Ruby? На мой взгляд — однозначно да. Их становится меньше и будет становиться еще меньше. Но старые проекты остаются. На мой взгляд, в таком ключе Ruby нужны инструменты для поддержки сложных, массивных приложений. В таких ситуациях неплохо взглянуть на такие дополнения, как система типов. Многие предпочитают поддерживать большие приложения и развивать их, как мы видим на примере JavaScript с Flow и TypeScript, в сторону типизации, которая немного упрощает рефакторинг и контроль за ситуацией в сложном проекте. Возможно, нужно делать более богатую экосистему библиотек, которую нужно использовать независимо, как, например, dry-rb. Где человек может выбрать, что ему нужно для валидации, что для построения эффектов в какой-то подсистеме. Возможно, ему нужны контейнеры внедрения зависимостей, которые решают определенные проблемы. Экосистема должна двигаться в эту сторону. В сторону энтерпрайз разработки и поддержки больших и сложных систем.
Обсудим на RubyRussia!
Приходите и вы, регистрация еще открыта.
Будут не только доклады, но и стенды классных компаний:
Организатор — Evrone
Генеральный партнер — Toptal
Золотой партнер — Gett
Серебряные партнеры — Валарм, JetBrains, Bookmate и Cashwagon
Бронзовый партнер — InSales
