来自手机的 Heroku 请求
我正在开发一个 iPhone 应用程序，它将与 Heroku 上托管的 Rails 应用程序进行通信。我想知道我应该如何调整服务器的大小（多少个测功机、工作人员以及什么类型的数据库）
据我了解，工作人员一次可以执行一个操作（例如：在数据库中执行选择），以及一个测功机可以同时处理 10 到 100 个请求。
如果手机连接速度较低，请求可能需要很长时间，这会对我的服务器产生什么影响？
我猜请求越长，并发请求就越多，因此需要更多的 dyno ？ 但这应该不会影响所需的工人数量，对吗？
那么标准数据库呢，除了 5Mo 的限制之外，对于 10 到 100 个同时请求是否太慢？ （每个表演都很简单 选择小于 5Mo 的数据库？）
谢谢， 文森特
I'm working on a iPhone application that will communicate with a rails app hosted on Heroku. I'm wondering how i should size the server (how many dynos, workers, and what type of database)
From what i understand a worker can perform i single operation at a time (ex: performing a select in database), and a dyno can handle between 10 and 100 simultaneous request.
If the phone has a low connection, requests might take a long time, how will this affect my server ?
I guess the longer the request are the more concurrent request there will be, so it requires more dyno ?
But it shouldn't affect the required number of worker, right ?
And how about the standard database, apart from the 5Mo limit, is it too slow for 10 to 100 simultaneous request ? (each performing very simple
Select on a less than 5Mo database ?)
Thanks,
Vincent
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
重要的是要记住，单个测功机是单线程的，因此如果您的响应时间（此处使用 New Relic）是 200 毫秒，那么您（理论上）能够使用单个测功机每秒处理 5 个请求。增加 dyno 并不会提高性能，而是会增加吞吐量 - 从这个角度来看，我们最近需要在广告后快速扩展应用程序，最终在大约 45 个 dyno 上运行（可能有点过分），并且每分钟处理大约 5600 个请求，因此大约 100 个请求请求一秒钟。另请记住，如果一直使用测功机（长时间运行的请求、上传等），那么如果您没有其他测功机要处理，则请求将排队，并且该队列最终将在 30 秒后超时。
我们正在运行 20Gb 数据库，并且在数据库响应时间方面看到了令人印象深刻的数字，当然该站点也使用 Memcached 层来保持敏捷。
希望有帮助，
约翰。
It's important to remember that a single dyno is single threaded, so if your response time (use New Relic here) is say 200ms you're (in theory) able to process 5 requests a second with a single dyno. Increasing dynos does not increase performance, it increases throughput - to put this in perspective we recently needed to scale an app rapidly after advertising and ended up running on around 45 dynos (probably overkill) and were dealing with around 5600 requests a minute so approximately 100 requests a second. Also remember that if a dyno is kept in use (long running request, upload etc) then if you don't have additional dynos to process then requests will be queued and that queue will eventually be timed out after 30 seconds.
We're running off the 20Gb database and have seen impressive figures in DB response time, of course the site is also using a Memcached layer too to keep it snappy.
Hope that helps,
John.