Heroku, Cedar stack: какие запросы занимают динамометрическое время - PullRequest
Новая
       31

Heroku, Cedar stack: какие запросы занимают динамометрическое время

1 голос
/ 19 ноября 2011

Я немного подумал о том, как рассчитать, сколько пользователей я могу обработать с помощью Heroku и одного dyno. Но чтобы понять это, мне нужно немного информации.

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

Так что мне нужно немного узнать о том, как Heroku, стек Cedar, работает в отношении запросов на мои расчеты.

Вы можете поправить меня в моих предположениях, поскольку я относительно новичок в теории динамо.

Допустим, у меня есть контроллер, который принимает запрос и вычисляет ответ JSON за 10 мс локально. Смогу ли я обслуживать 100 запросов в секунду?

Как я понимаю, в стеке кедров нет фронтального решения для кэширования, возникает много вопросов.

  1. Занимает ли запросы статического контента дольше времени?
  2. Учитывается ли время передачи для запроса времени.
  3. Может ли одно решение dyno одновременно передавать несколько ответов на запрос, если запрос требует небольшой загрузки ЦП.

Некоторые вопросы взаимосвязаны, поэтому ценный ответ или другая мысль ценится.

Пример:

Статическая HTML-страница. 

<HTML>...<img><css><script>...
AjaxCall //dyno processing time 10ms
AjaxCall //dyno processing time 10ms
AjaxCall //dyno processing time 10ms
AjaxCall //dyno processing time 10ms
...</HTML>

Можно ли подавать (1000 мс / (10 мс х 4)) = 25 страниц HTML в секунду?

  • Предполагается, что статический контент не предоставлен dyno.
  • Предполагается, что время передачи не обвинило динамометра.

Если бы это было не так, я был бы катастрофой . Допустим, мобильный телефон в Африке делает 10 запросов и время передачи 10 секунд, тогда мое приложение будет недоступно более 1½ минуты.

Ответы [ 2 ]

2 голосов
/ 19 ноября 2011

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

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

Также, когда речь идет о времени динамометрии, которое относится к количеству времени, в течение которого выполняется ваш процесс, а не только к времени обработки запроса. Таким образом, веб-процесс, ожидающий запрос, по-прежнему потребляет длительное время, так как процесс запущен и ожидает запросов. Вот почему вы получаете 750 бесплатных часов в месяц. Вы сможете запустить один динамо за весь месяц (720 часов).

Что касается вычисления количества запросов, которое ваше приложение может обрабатывать в секунду, то лучший способ сделать это - протестировать его. Вы можете использовать New Relic для мониторинга своего приложения во время нагрузочного тестирования с помощью JMeter или любой другой любимой программы нагрузочного тестирования: http://devcenter.heroku.com/articles/newrelic

2 голосов
/ 19 ноября 2011

Я действительно могу ответить только на первый вопрос: статические активы, безусловно, занимают динамо-время. На самом деле, я думаю, что лучше использовать все статические ресурсы, включая таблицы стилей и JS, на сервере ресурсов при использовании бесплатного пакета heroku. (Если бы все так делали, то героку было бы полезно, и вы тоже). Я рекомендую использовать гем asset_sync , чтобы справиться с этим. В файле Readme объясняется, что существует одна или две легко решаемые текущие проблемы.

Что касается вашего последнего замечания, извините, если я здесь неверно истолковал, но пользователю в Южной Африке может потребоваться 10 секунд, чтобы направить его запрос в Heroku, но большую часть этого времени, вероятно, тратят на пересылку по лабиринту телефонных станций между SA и США. Ваш динамо связан только с той частью запроса, которая выполняется на серверах Heroku, а не с 9,9 секундами, которые ваш запрос потратил на его получение. Таким образом, Heroku не знает, поступает ли ваш запрос из Южной Африки или Швеции.

Для ускорения работы вашего приложения вы можете делать самые разные вещи: кеширование, больше динамометрических систем, единорог с несколькими работниками

...