Как получить больше производительности от ruby?

Question

[Jeket]

Есть задача фоновой обработки большого количество данных:
на вход подается 10 тысяч записей в секунду, происходит обработка и далее отдается в базу все эти 10 тысяч записей.

Пока делаю решение на одной машине (вариант нескольких серверов пока не рассматривается).
Сейчас думаю о двух вариантах:
1) запуск нескольких потоков, но тут возникает опасность блокировки потока
2) параллельный запуск нескольких экземпляров обработчика

Какой вариант будет быстрее? Может кто-нибудь сталкивался с увеличением производительности ruby?

Answer 1

[vsuhachev]

Вполне может так случится, что узким местом будет СУБД. Попробуйте просто без обработки сохранить этот массив в базу и если это не получится, то оптимизировать Ruby не имеет смысла, нужно искать более шуструю СУБД, я знаю что например в промышленности, где так же стоит задача сохранять огромные массивы инфы с датчиков используют key-value СУБД, у которых на вставку скорости сильно больше чем у реляционок.

Answer 2

[Viktor Vsk]

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

У вас рельсы или нет? Какой у вас ОРМ ? Какая база? 10000 каких записей? Что за обработка происходит? Что в базе должно произойти с этими 10000 ?

Какие условия? Надо за 1 секунду полностью обработать первые 10000 и приступить к следующим? Или покатит очередь ? Если очередь, то с приоритетом\последовательностью ? Управлением? Какой ресурс сервера?

Не страдайте преждевременной оптимизацией. Поставьте задачу, решите самым простым и быстрым способом. Если упретесь в числа, то уже задавайтесь вопросами.

Обычно индексация, правильный движок таблиц и какой-нибудь https://github.com/zdennis/activerecord-import или вручную составленный запрос решают проблему. Если нет и условия не сильно жесткие, то очереди.

Ну а дальше уже только конкретика.

Comments

[Jeket]

Задача следующая - есть внешний источник информации, который предоставляет ее по запросу, формат входных данных json (планирую полученные данные хранить у себя в redis-е, на время обработки), далее я параллельно с этим беру справочные данные из другой базы, затем произвожу вычисления входных данных с учетом справочников и сохраняю все это дело в третью базу (возможен вариант сохранения в базу со справочниками).

[vsuhachev]

@Jeket а ограничение 10000 записей в секунду откуда? Это желаемая вами производительность или это жесткое условие?

[Jeket]

это требование ТЗ

Answer 3

[FanKiLL]

https://github.com/resque/resque
Так же в рельсах 4.2.0 появится собственная очередь, так что пока можно использовать resque
а потом перейти на встроенную очередь.

Active Job, ActionMailer #deliver_later
The headline feature for Rails 4.2 is the brand new Active Job framework, and its integrations. Active Job is an adapter layer on top of queuing systems like Resque, Delayed Job, Sidekiq, and more. You can write your jobs to Active Job, and they'll run on all these queues with no changes.

Comments

[Сергей Той]

Кстати, ActiveJob, это лишь абстракция для работы с Resque, Sidekiq, DJ и кучей других (edgeapi.rubyonrails.org/classes/ActiveJob/QueueAda... Так что смело можно использовать Resque, а потом просто переключиться на прослойку ActiveJob, продолжая на бекенде использовать Resque.