Целесообразно ли использовать Celluloid/Sidekiq & Rails 3.2 с MRI Ruby и приложением, ранее не предназначенным для обеспечения безопасности потоков?

Question

У меня есть большой проект, работающий на MRI Ruby и Rails 3.2 для Passenger, с приложением, которое не было разработано с учетом безопасности потоков, и это приложение обрабатывает почтовые сообщения через DelayedJob, и база данных платит за это высокую цену.

Некоторые возможные проблемы упомянуты в sidekiq railscast http://railscasts.com/episodes/366-sidekiq включая:

1. ограничение на соединение с базой данных (при использовании пула потоков, равного 1, предел соединения с БД должен быть удвоен)
2. потокобезопасность (это, вероятно, пробка шоу)
3. волоконно-безопасности? Это проблема с AR?

Итак, вопрос:

1. Насколько жизнеспособным является сделать большой проект потокобезопасным, чтобы генерация почты работала в потоках внутри пассажирского процесса? (рассылки достаточно сложны, чтобы зависеть от AR)
2. тот же вопрос при использовании sidekiq: "Насколько жизнеспособно сделать большой проект потокобезопасным, чтобы генерация почты работала с использованием sidekiq? (почтовые сообщения достаточно сложны, чтобы зависеть от AR)"
3. кроме ограничения соединения с БД и безопасности потоков, есть ли что-то еще, чтобы рассмотреть или менее очевидные ошибки, которые я не смог предвидеть?

Answer 1

Я думаю, что вы здесь что-то путаете.

Я никогда не использовал sidekiq, но я не думаю, что вы должны включить thread_safe! в вашем приложении Rails, чтобы использовать его.

AFAIK, это просто для обработки запроса, чтобы иметь блокировку или отсутствие блокировки в thread_safe! режим, поэтому процесс Rails может обрабатывать несколько запросов параллельно.

При использовании sidekiq это не должно быть одной из ваших проблем. Только ваш код обработки электронной почты должен быть поточно-ориентированным. Только тот, кто сопровождает проект, может ответить на этот вопрос.