Распараллеливание методов в Rails

Вы можете взглянуть на новую опцию в городе: Камень футороскопа . Как вы можете видеть из анонса блога , он пытается решить ту же проблему, с которой вы сталкиваетесь, выполняя одновременные запросы API. Кажется, у него довольно хорошая поддержка и хорошее тестовое покрытие.

Предполагая, что ваша проблема - медленный внешний API, решением может быть использование либо многопоточного, либо асинхронного программирования. По умолчанию при выполнении ввода-вывода ваш код будет заблокирован. По сути, это означает, что если у вас есть метод, который выполняет HTTP-запрос для извлечения некоторого JSON, ваш метод сообщит вашей операционной системе, что вы собираетесь спать, и вы не хотите, чтобы его разбудили, пока операционная система не получит ответ на этот запрос. Поскольку это может занять несколько секунд, вашему приложению просто придется ждать.

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

Итак, вопрос в вашем случае: нужно ли нам ждать завершения одного метода, прежде чем мы сможем вызвать другой? В случае, если поведение method_two зависит от результата method_one, тогда да. Но в вашем случае кажется, что это отдельные единицы работы без взаимозависимости. Таким образом, существует потенциал для выполнения параллелизма.

Вы можете запускать новые потоки, инициализируя экземпляр класса Thread блоком, содержащим код, который вы хотите запустить. Думайте о потоке как о программе внутри вашей программы. Ваш интерпретатор Ruby будет автоматически переключаться между потоком и вашей основной программой. Вы можете запустить столько потоков, сколько захотите, но чем больше потоков вы создадите, тем дольше ваши основные программы будут ждать, прежде чем вернуться к выполнению. Тем не менее, мы, вероятно, говорим микросекунды или меньше. Давайте рассмотрим пример многопоточного исполнения.

def main_method
  Thread.new { method_one }
  Thread.new { method_two }
  Thread.new { method_three }
end

def method_one
  # something_slow_that_does_an_http_request
end

def method_two
  # something_slow_that_does_an_http_request
end

def method_three
  # something_slow_that_does_an_http_request
end

Вызов main_method вызовет выполнение всех трех методов в том, что кажется параллельным. В действительности они все еще обрабатываются последовательно, но вместо того, чтобы переходить в спящий режим, когда блоки method_one блокируются, Ruby просто вернется в основной поток и переключится обратно в поток method_one, когда ОС подготовит входные данные.

Если предположить, что на выполнение каждого метода уходит две 2 мс минус ожидание ответа, это означает, что все три метода запускаются через 6 мс - практически мгновенно.

Если мы предположим, что для ответа требуется 500 мс, это означает, что вы можете сократить общее время выполнения с 2 + 500 + 2 + 500 + 2 + 500 до всего 2 + 2 + 2 + 500 - другими словами от 1506 мс до 506 мс.

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

В вашем случае, однако, у вас есть проблема, потому что у вас есть операция, которая зависит от завершения набора предыдущих операций. Другими словами, если у вас есть задачи A, B, C, D, E и F, то A, B, C, D и E могут выполняться одновременно, но F не может выполняться до A, B, C, D и E. все завершены.

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

def task_1
# Something slow
return results
end

def task_2
# Something slow
return results
end

def task_3
# Something slow
return results
end

my_responses = {}
Thread.new { my_responses[:result_1] = task_1 }
Thread.new { my_responses[:result_2] = task_2 }
Thread.new { my_responses[:result_3] = task_3 }

while (my_responses.count < 3) # Prevents the main thread from continuing until the three spawned threads are done and have dumped their results in the hash.
  sleep(0.1) # This will cause the main thread to sleep for 100 ms between each check. Without it, you will end up checking the response count thousands of times pr. second which is most likely unnecessary.
end

# Any code at this line will not execute until all three results are collected.

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

Если вы хотите заняться многопоточным программированием, я рекомендую эту книгу: http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

Он сосредоточен вокруг Явы, но объясненные ловушки и концепции универсальны.

Вы должны проверить Sidekiq .

RailsCasts эпизод о Sidekiq.