Готовая комбинация Thin + Nginx Production для приложения RubyOnRails - PullRequest
3 голосов
/ 17 февраля 2009

Я недавно установил Nginx + Thin на свой сервер развертывания, но я не уверен, как это будет работать в ситуации с последними запросами и ответами. скажем 1000 / Req в сек.

так что скорость на худой скорости хороша с 10-100 req / sec

Я хотел бы знать о больших объемах данных, обрабатываемых в кластере запросов / ответов.

Направь меня на это: -)

Ответы [ 2 ]

3 голосов
/ 17 февраля 2009

Несколько тонких процессов и nginx способны обеспечить высокую скорость, в зависимости от того, что делает ваше приложение. Таким образом, проблема заключается в коде вашего приложения, скорости вашего сервера приложений и сервера базы данных.

Scaling Rails недавно был подробно освещен в Scaling Rails Screencasts . Я рекомендую вам начать там. Моя 5-шаговая программа для масштабирования Rails будет:

  1. Первый шаг - иметь инструменты, чтобы посмотреть, что медленно работает в вашем приложении. Не тратьте время на оптимизацию всего в своем приложении, если не знаете, в чем проблема.
  2. Самый простой способ обрабатывать множество запросов в секунду - это кэширование страниц.
  3. Если вы не можете этого сделать, кэшируйте все возможное (кэширование фрагментов, используйте memcached для кэширования данных и т. Д.), Чтобы ускорить работу вашего приложения.
  4. После этого оптимизируйте приложение как можно лучше, ускоряйте запросы SQL, индексируйте все и т. Д.
  5. Если вам все еще нужна большая скорость, добавьте больше оборудования к проблеме. Получите большой, мощный сервер баз данных, несколько серверов приложений и прокси-запросы к ним. Вы также можете начать здесь, но это только задержит процесс оптимизации.
0 голосов
/ 19 февраля 2009

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

Это также хорошая идея, чтобы monit или God контролировали ваши тонкие экземпляры, я начал с God, но он очень плохо просочился в Ruby 1.8.6, поэтому я перестал использовать его в пользу monit. Я считаю, что Monit написан на C и имеет небольшой объем памяти, поэтому я бы порекомендовал его.

Если все, что вам нужно, чтобы nginx и тонко играли хорошо, кажется, вам нужно рассмотреть все в одном решении, таком как Passenger или LiteSpeed. У меня очень мало опыта работы с ними, поэтому я не могу предложить им никаких финансовых рекомендаций.

...