Ответ 1

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

Вопрос 2: Ограничивающим фактором для Ruby concurrency в целом, а не только с Rails, является Global Interpreter Lock. Эта функция Ruby предотвращает выполнение более 1 потока Ruby в любой момент времени для каждого процесса. Блокировка освобождается всякий раз, когда выполняется выполнение не Ruby-кода, например, ожидание ответов на ввод IO или SQL. Вы можете обойти это, используя другую реализацию Ruby, чем по умолчанию, например JRuby, но не все. Там хорошее объяснение GIL здесь.

Phusion Passenger использует процесс на основе concurrency для обработки нескольких запросов одновременно, поэтому строго говоря, это не "многопоточность", но все же параллельна.

В этом разговоре от Ruby MidWest 2011 есть несколько хороших мыслей о том, как многопоточно работать с Ruby on Rails.

Ответ 2

Поскольку речь идет о "от ASP.NET к RoR", есть еще одна небольшая, но важная деталь для запоминания: в средах * nix обычно достигается concurrency приложения-службы посредством многопроцессорной обработки, а не многопоточности. Это архитектура, которая идет назад и связана с относительно дешевой стоимостью многопроцессорной обработки на системах * nix, используя fork и Copy-on-Write. Каждый процесс обрабатывает один запрос за один раз в одном потоке, а основной процесс контролирует нереста и убивает рабочие дочерние процессы. Несколько запросов подаются одновременно разными дочерними процессами.

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

В случаях, когда приложение было создано с возможностью переносимости (примеры снова: Apache, MySQL и т.д.), его обычно запускать в многопроцессном или комбинированном режиме на системах * nix и в многопоточном режиме в Windows серверы.

Однако, по общему признанию, Rails не хватает на передней панели Windows. Это не значит, что вы не можете запускать его в Windows, это просто не так много усилий, чтобы убедиться, что он работает хорошо и плавно для использования на серверах Windows. Это не обычная производственная платформа среди сообщества RoR.

В результате, Eventhough Rails сам по себе является потокобезопасным с версии 2.2, для него на сервере Windows пока нет хорошего многопоточного сервера. И вы получите наилучшие результаты, запустив его на серверах * nix с помощью многопроцессорной/однопоточной модели concurrency.

Ответ 3

Рельсы в качестве фреймворка являются потокобезопасными. Итак, ответ да!

Вторая ссылка, которую вы разместили здесь, называет многие серверы Rails, которые не преуспевают в многопоточности. Позже он упоминает, что nginx - это способ пойти (это, безусловно, самый популярный и очень рекомендуется). Но он не упоминает, что заставило его подойти к выводам. Ruby 1.9.3 вышел недавно, и у него появилось новое качество резьбы, которое раньше не существовало.

Использование многопоточности обычно зависит от варианта использования. Лично я пробовал это один раз год назад, и это сработало, но я не использовал его ни в одном производственном коде, потому что я не сталкивался с прецедентом, когда использование многопоточности делало больше смысла в том, чтобы подталкивать долговременную задачу к фоновая работа.

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