Всем привет! Мы начинаем новую неделю и с вами @KernelMadness

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

На этой неделе я планирую поговорить с вами про производительность Ruby, построение больших систем и будущее веб-разработки

Давайте проголосуем, как вы решаете вопросы с производительностью в Ruby?

Пока вы голосуете, хочу сказать вот что: Ruby совершенно замечательный язык, красивый и гибкий. Но эта гибкость обходится очень дорого.

Как показывает практика, серьезные алгоритмы в нем лучше не реализовывать. Работа с памятью и объектами далеко не быстрая.

Иногда спасают альтернативные реализации, но даже они вынуждены тащить с собой всю сложность языка и прирост скорости там не капитальный

Для наших целей мы стараем все сложные манипуляции с данными проводить в SQL, и это работает. Postgres делает это очень эффективно.

В Ruby мы производим сборку запроса и БД его исполняет. И да, многостраничные простыни у нас не редкость :)

Если у вас есть опыт работы с большими данными - поделитесь! Что использовали, какие объемы?

Одна из важнейших составляющих производительности в Ruby - это его GC. И это я бы хотел обсудить с вами, уважаемые фолловеры.

На прошедшем Ruby-митапе в Рамблере был отличный доклад про устройство GC. К сожалению нет видео под рукой, может у кого то есть ссылка?

В дополнение к предыдущему, вот еще один доклад от Тимофея Цветкова youtube.com/watch?v=iGlcG4…

Эти 2 доклада позволяют понять, как работает GC в Ruby. Если в кратце, то лучше чем раньше. Но все равно не ок :)

В итоге, это приводит к тому что сложные приложения потребляют память гигабайтами. Как бороться? Есть несколько способов, но об этом далее

Самое простое - unicorn-worker-killer и его аналоги. Работает просто - перезапукает ruby-процесс по достижению лимита памяти

Следующий этап - разобраться в вашем коде. Злоупотребление гемами, неоптимальные алгоритмы - это все замедляет ваше приложение.

Зачастую некоторые вещи лучше и проще написать самому, чем тащить в проект непонятные блекбоксы с кучей зависимостей

@rubyunderhood профайлеры наше все в таком случае

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

Далее, тюнинг GC. Довольно забавное занятие, учитывая что нормальный GC вообще не должен о себе напоминать... Но, наш GC очень простой

И в нем можно разобраться. После прослушивания тех двух докладов про GC его переменные обретают вполне конкретный смысл

@rubyunderhood nateberkopec.com/2015/08/05/rac…

Про альтернативные реализации: JRuby, Rubinius. Я не сторонник таких средств, но в JRuby родной GC от JVM внушает уважение.

Можно пробовать, если в проекте нет зависимостей от расширений на C для MRI.

Что думаете насчет ActionCable? Кто пробовал уже?

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

Что вы используете для реализации сокетов? Faye? ActionCable? Другое решение? Возможно даже на другом языке

@rubyunderhood так уже выяснили, что можно без них жить прекрасно
samsaffron.com/archive/2015/1…

@rubyunderhood чаще всего использую обычный em и руками все пишу

@rubyunderhood Faye

@rubyunderhood В попытках собрать комьюнити в Харькове facebook.com/groups/rubykh/ . Цель - пить пиво и общение. Прошу репост.

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

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

И как обычно это приложение активно используется в продакшене, надо поддерживать в нем жизнь и дорабатывать дальше

Что делать в этой ситуации? Оптимизировать то что есть, разделять на микросервисы? Поделитесь своим опытом

А пока что голосовалка.
Ваш проект:

@rubyunderhood мне кажется - разделять. Ну я стараюсь разделять еще до того, как все выходит из под контроля.

Я опубликовал "Надежный деплой Rails приложений" :) Принимаю критику, поздравления, вопросы и пожелания :) bit.ly/20vPan2

Друзья, а поделитесь кто что использует для обработки очередей? И почему?

@rubyunderhood последний раз вот так делал bytes.babbel.com/en/articles/20…

@rubyunderhood на mkdev все проще (чай не десятки тысяч событий в минуту) - sidekiq.

@rubyunderhood, Active Job + Sidekiq + Redis - в моих проектах хватает с головой, очереди небольшие и легкообрабатываемые

Sidekiq - хорошая штука. А что насчет утечек памяти, есть проблемы?

@rubyunderhood перевели все на sidekiq около пол года назад, около 10+ api, полет ок

@rubyunderhood для общения основного апп с серисами rabbitmq. На микросервисах сникерсы слушают и отвечают

@pstepchenko @rubyunderhood да, могу рассказать, задавайте вопросы, постараюсь ответить :)

У кого был опыт решения проблем с текучкой памяти/производительностью путем перехода на другие языки? Elixir/Go/Etc. Поделитесь опытом?

@rubyunderhood и при этом клиентская часть должна это переварить)

И кстати да, мы сейчас активно хантим умных ребят! Ищем тех, кто опытен в руби, но не ограничивается им и знает что то еще: Elixir/Go/Node.

Так что если вам надоело работать на текущем месте и вы хотите писать крутые штуки - напишите мне @KernelMadness

Но если честно, я уже забыл когда мы в последний раз двигали кнопки @mr_The, кроме шуток

А еще мы очень любим SQL, и активно эксплуатируем наши базы. По опыту, 95% рубистов которые к нам приходили, не знали ничего сложнее JOIN

Но мы любим учить, и поэтому уже через несколько месяцев они спокойно пишут большие оптимизированные запросы с агрегациями, оконками, и тд

Производить какие-либо вычисление в ruby практически невозможно. Его предназначение - перекладывать данные из одного места в другое

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

В силу техпроцесса, мы имеем возможность за адекватные деньги дать много данных по всей стране.

Дорогие рубисты, наше с вами время подходит к концу. Эту неделю провел @KernelMadness, было круто со всеми пообщаться!