Heroku、Cedar 堆栈：哪些请求占用了 dyno 时间
我已经考虑过如何计算使用 Heroku 和一台 dyno 可以处理多少用户。 但要弄清楚我需要一些输入。
我必须说，官方文档不太好浏览和解释，所以我还没有全部读完。我对此的抱怨是它没有很好地描述事物。有时它描述旧堆栈，有时它是特定于 ruby 的，有时它根本没有描述等等。
因此，我需要一些关于 Heroku、Cedar 堆栈如何处理请求的信息来进行计算。
非常欢迎您纠正我的假设，因为我对动力理论相对较新。
假设我有一个控制器，它接受请求并在 10 毫秒内计算出本地的 JSON 响应，我能够每秒处理 100 个请求吗？
据我了解，雪松堆栈没有前端缓存解决方案，因此出现了许多问题。
- 静态内容请求会占用 dyno 时间吗？
- 传输时间是否计入请求时间。
- 如果请求需要的 CPU 利用率较低，那么一个 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>
我可以每秒提供 (1000ms / (10ms x 4)) = 25HTML 页面吗？
- 这假设静态内容不是由 dyno 提供的。
- 这假设传输时间不归咎于测功机。
如果不是这样的话，我将是一场灾难。假设非洲的手机发出 10 个请求，传输时间为 10 秒，那么我的应用程序将在超过 1.5 分钟内不可用。
I have given some thought on how to calculate how many users I can handle with Heroku and one dyno.
But to figure it out I need some input.
And I must say that the official documentation isn't nice to navigate and interpreter so I haven't read it all. My complaints about it are that it doesn't describe things very well. Sometimes it describes old stacks, sometimes it's ruby specific, sometime it isn't described at all and so on.
So I need some input on how Heroku, Cedar stack, works regarding requests to make my calculations.
You are more than welcome to correct me on my assumptions as I am relatively new to dyno theory.
Lets say I have a controller that takes a request and calculate a JSON response in 10ms locally will I be able to serve 100request a second?
As I understand the cedar stack doesn't have a fronting caching solution, many questions arises.
- Does static content requests take up dyno time?
- Does transfer time count to request time.
- Can one dyno solution transfer many response to a request at the same time if the request requires small CPU utilization.
Some of the question is intertwined so a combined answer or other thought is valued.
An example:
Static HTML page.
<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>
Can I serve (1000ms / (10ms x 4)) = 25HTML pages a second?
- This assumes that static content isn't provided by a dyno.
- This assumes that transfer time isn't blamed on the dyno.
If this isn't the case I would be a catastrophe. Lets say a mobile phone in Africa makes 10 request and have a 10sec transfer time then my App will be unavailable for over 1½ minute.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你做出了两个错误的假设。好消息是，一旦你以不同的方式思考问题，你的问题就会变得简单得多。
首先请记住，dyno 是单个进程，而不是单个线程。如果您使用 Java，那么您将使用许多请求线程。因此，您不必担心在处理请求时您的应用程序不可用。您将能够并行处理请求。
另外，当谈论动态时间时，它指的是进程运行的时间，而不仅仅是请求处理时间。因此，等待请求的 Web 进程仍然会消耗 dyno 时间，因为该进程在等待请求时已启动。这就是您每月获得 750 个免费 dyno 小时的原因。您将能够在整个月（720 小时）内运行单个测功机。
至于计算应用程序每秒可以处理多少个请求，最好的方法就是对其进行测试。您可以使用 New Relic 来监视您的应用程序，同时使用 JMeter 或任何您最喜欢的负载测试程序进行负载测试： http://devcenter.heroku.com/articles/newrelic
You're making two wrong assumptions. The good news is that your problem becomes much simpler once you think about things differently.
First off remember that a dyno is a single process, not a single thread. If you're using Java then you'll be utilizing many request threads. Therefore you don't have to worry about your application being unavailable while a request is being processed. You'll be able to process requests in parallel.
Also when talking about dyno time that refers to the amount of time that your process is running not just request processing time. So a web process that is waiting for a request still consumes dyno time since the process is up while it waits for requests. This is why you get 750 free dyno hours a month. You'll be able to run a single dyno for the entire month (720 hours).
As far as computing how many requests your application can serve per second the best way to do that is to test it. You can use New Relic to monitor your application while you load test it with JMeter or whatever your favorite load testing program is: http://devcenter.heroku.com/articles/newrelic
我只能真正回答第一个问题：静态资产肯定会占用动态时间。事实上，我认为在使用heroku的免费包时最好将所有静态资源（包括样式表和JS）保留在资源服务器上。 （如果每个人都这样做，heroku 将会受益，你也会受益）。我建议使用 asset_sync gem 来处理这个问题。自述文件确实解释了当前存在一两个易于解决的问题。
关于你的最后一点，抱歉，如果我在这里误解了，但是南非的用户可能需要 10 秒钟才能将他们的请求路由到 Heroku，但大部分时间可能都花在了南非和美国之间电话交换的迷宫中。 。您的 dyno 仅与 Heroku 服务器内发生的请求部分相关，而不是您的请求到达那里所花费的 9.9 秒。因此，Heroku 实际上不会注意到您的请求是来自南非还是瑞典。
您可以采取各种措施来加快应用程序的速度：缓存、更多测功机、具有多个工作线程的独角兽
I can only really answer the first question: Static assets most certainly do take up dyno time. In fact, I think it's best to keep all static assets, including stylesheets and JS on an asset server when using heroku's free package. (If everyone did that, heroku would benefit and so would you). I recommend using the asset_sync gem to handle that. The Readme does explain that there are one or two, easily resolved, current issues.
Regarding your last point, sorry if I'm misinterpreting here, but a user in south africa might take 10 seconds to have their request routed to Heroku, but most of that time is probably spent trafficking around the maze of telephone exchanges between SA and USA. Your dyno is only tied up for the portion of the request that takes place inside Heroku's servers, not the 9.9 seconds your request spent getting there. So effectively Heroku is oblivious to whether your request is coming from South Africa or Sweden.
There are all sorts of things you can do to speed your app up: Caching, more dynos, Unicorn with several workers