Героку |Различные параметры производительности для разных частей вашего приложения - PullRequest
2 голосов
/ 23 марта 2011

У меня есть приложение на Rails 3, размещенное на heroku, оно имеет довольно распространенную конфигурацию, где у меня есть клиент, обращенный к части моего приложения, например: www.myapplication.com, и часть администратора моего приложения admin.myapplication.com.

Я хочу, чтобы моя клиентская часть моего приложения работала быстро, и мне все равно, насколько быстрым является мой модуль администратора.Что меня беспокоит, так это то, что я не хочу, чтобы использование на моем административном сайте замедляло работу клиентской части моего приложения.

В идеале на моей клиентской стороне приложения есть 3 выделенных динамо и мой администратор.сторона будет иметь 1 выделенный динам.

У кого-нибудь есть идеи о том, как лучше всего это сделать?

Спасибо!

Ответы [ 2 ]

2 голосов
/ 24 марта 2011

Если вы разделите приложения, у вас будет общий доступ к базам данных между двумя приложениями.Честно говоря, я бы просто создал одно приложение и дал бы ему 4 dynos:)

Кроме того, Dynos не увеличивает производительность, они увеличивают пропускную способность, поэтому вы способны обрабатывать больше запросов в секунду.,

Например,

Грубо - если типичный отклик страницы составляет 100 мс, 1 динам может обрабатывать 10 запросов в секунду.Если у вас есть только один dyno, и ваше приложение неожиданно получает 10 запросов в секунду, то лишние запросы будут помещены в очередь, пока dyno не будет свободен для обработки этих запросов.Кроме того, для запросов> 30 будет превышено время ожидания.

Если вы добавите вторую динамограмму, запросы будут разделены между двумя динамо, так что теперь вы сможете обрабатывать 20 запросов в секунду (в идеальном мире) и т. Д.Если вы добавляете больше dynos.

И помните, что dyno является однопоточным, поэтому, если он что-то делает ANYTHING , то есть, рендеринг страницы, создание pdf и получение загруженного изображения и т.д.занят и не может обрабатывать дальнейшие запросы до тех пор, пока он не будет завершен, и если у вас не будет больше dynos, запросы будут поставлены в очередь.

0 голосов
/ 26 апреля 2013

Мой совет - разбить ваше приложение на логические части. Хорошо иметь отдельное приложение для интерфейса администратора.

Не обязательно находиться в том же домене, что и основное приложение. У него может быть глобальное ограничение IP-адреса клиента или просто глобальная базовая аутентификация.

Зачем усложнять вещи и складывать две вещи в одно приложение? Это также позволяет вам больше работать с административной частью и повторно развертывать ее, не затрагивая ваших пользователей.

...