托管高流量 Facebook 应用程序（游戏）
我们目前正在开发一个高流量的 Facebook 应用程序。所有流量都将在一个月内完成，预计用户数量为 500.000 至 1.000.000。 该月之后，游戏结束，我们有了获胜者 - 因此该应用程序将被存档。
我们目前正计划使用 Ruby on Rails 开发应用程序，并寻找可以处理流量的托管选项。问题不在于用户，而在于峰值：我们每天都会在短时间内收到大约 500,000 个请求（最坏情况下在 3 分钟内），
我们预计该应用程序的用户数量为 500,000 到 1,000,000 个，峰值时间为下午 1:00（GMT+1 时区），大多数（最多 80% 的用户）将发送大部分请求。请求时间为 6 月 11 日至 7 月 11 日 - 此后，应用程序/游戏将关闭/结束。
我们目前正在开发一种积极的缓存机制 - 目前我们正在考虑 2 或 3 个小型应用程序/网络服务来处理负载。
负载分布如下： a) 主应用程序，缓存数据（11 个屏幕，每个 200k） b) 投票：每天截止到下午1:00（GMT+1时区）——每个用户投票，发送数据约10k，并发峰值高！
问题：
- 有什么值得推荐的特定应用程序设置吗？
- 有没有可以推荐的托管合作伙伴？
谢谢！
we are currently developing a high traffic facebook application. all the traffic will be within one month, where there are 500.000 to 1.000.000 expected users.
after that month, the game is over and we have a winner - so the app will be archived.
we are currently planning to develop the application with ruby on rails and searching for hosting options that can deal with the traffic. the problem is not so much the users, but the peak values: we will have around 500.000 requests coming daily within a short timeframe (lets say within 3 minutes in the worst case)
we are expecting 500.000 to 1.000.000 users of the application, with peaks at 1:00pm (timezone GMT+1), where most (up to 80% of the users) will send most of the requests. the requests are from 11th of june to 11.july - after that, the app/game is closed/over.
we are currently developing an aggressive caching mechanism - currently we are thinking about 2 or 3 small apps/webservices, that will handle the load.
the load is distributed as follows:
a) main application, cached data (11 screens, 200k each)
b) voting: every day until 1:00pm (timezone GMT+1) - every user votes with about 10k data sent, high concurrent peak values!
questions:
- is there any specific application setup that is recommendable?
- are there any hosting partners that can be recommended?
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，如果您提供的内容全部被缓存，那么您就可以了，几个 nginx 实例可以提供几乎无限的静态页面。
投票听起来不太好，因为它应该同时进行。
高并发负载的新热门似乎是node.js，但我对此没有任何经验。
我确实认为投票实际上不会做太多事情，所以不要进行完整的 Rails 堆栈调用，而是尝试编写一个小机架方法来完成投票。这可以让您免于加载 ActionController、ActionView，如果您使用纯 SQL 也将投票写入数据库，还可以使用 ActiveRecord。
Well if the content you serve out is all cached then you are good with that, a few nginx instances can serve almost unlimited static pages.
The voting sounds less nice since it is supposed to happen all at the same time.
The new hotness for high concurrent loads seems to be node.js but I don't have any experience with that.
I do think though that the voting will not actually do very much so instead of doing a full rails stack call try to just write a small rack method that accomplishes the voting. That saves you from loading ActionController, ActionView and if you write your votes to the DB in plain SQL also ActiveRecord.
查看一些自动扩展云计算解决方案，例如 EC2 的 AutoScaling http://aws.amazon.com/autoscaling/< /a> 您设置 EC2 何时为您启动新实例的参数。
如果您确实想小心，则可以构建一个僵尸网络来模拟您网站的流量 http://www.talcottsystems.com/articles/build-your-own-botnet-with-ec2- and-capistrano-to-load-test-your-server-cluster-before-launch/
Check out some auto scaling cloud computing solutions such as EC2's AutoScaling http://aws.amazon.com/autoscaling/ you set parameters as to when EC2 will spin up new instances for you.
If you really want to be careful you can then build a botnet to simulate traffic to your site http://www.talcottsystems.com/articles/build-your-own-botnet-with-ec2-and-capistrano-to-load-test-your-server-cluster-before-launch/