Я прочитал тонны материала в Интернете о безопасности потоков и производительности в различных версиях ruby и rails, и я думаю, что на данный момент я достаточно хорошо понимаю эти вещи.

То, что кажется странным образом отсутствующим в обсуждениях, это то, как на самом деле развернуть асинхронное приложение Rails. Говоря о потоках и синхронности в приложении, люди хотят оптимизировать две вещи:

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

Точка 1 - то, где люди (справедливо) взволнованы по поводу JRuby. По этому вопросу я только пытаюсь оптимизировать пункт 2.

Скажем, это единственный контроллер в моем приложении:

TheController < ActionController::Base
  def fast
    render :text => "hello"
  end

  def slow
    render :text => User.count.to_s
  end
end

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

Таким образом, идеальное развертывание позволит сотням запросовfast должно быть выполнено во время запросаslow ждет на IO.

То, что, по-видимому, отсутствует в дискуссиях вокруг Интернета, это то, какой слой стека отвечает за включение этого параллелизма. тонкий имеет--threaded флаг, который будет вызывать приложение Rack в потоках [экспериментальный] - это запускает новый поток для каждого входящего запроса? Подпишите экземпляры стоечного приложения в потоках, которые сохраняются и ждут входящих запросов?

Тонкий единственный путь или есть другие? Имеет ли значение время выполнения ruby для оптимизации пункта 2?