Here's a scenario: I have a 'data-feed' - a REST/JSON service that updates periodically (let's say - every 10 seconds or so), and if a change in the data set occurs - then all subscribed listeners need to be updated.
这是一个场景:我有一个'数据提要' - 一个定期更新的REST / JSON服务(假设 - 每10秒左右),如果数据集发生了变化 - 那么所有订阅的监听器都需要更新。
It's currently implemented using long-polling over HTTP, which is a technicality - but the main concept is that clients don't bother the server, and the server doesn't bother the clients - unless there's something to bother about. When there is something new, all clients get notified immediately. The technology consists of Java/Tomcat7, async IO (asyncResponse).
它目前使用HTTP上的长轮询实现,这是一个技术性 - 但主要的概念是客户端不打扰服务器,服务器不打扰客户端 - 除非有什么值得烦恼的。当有新的东西时,立即通知所有客户。该技术由Java / Tomcat7,异步IO(asyncResponse)组成。
I think it works great: I can drive 10K concurrent sessions for ~ $0.07 per hour (AWS M3.Medium instance).
我认为它很有效:我可以每小时约0.07美元(AWS M3.Medium实例)驱动10K并发会话。
(Question - I think it works great, but I would like to hear some benchmark numbers to verify. Or in other words - do you think it's a good bang for the buck? please share !!)
(问题 - 我认为它很有效,但我希望听到一些基准数据来验证。或者换句话说 - 你认为这是一个很好的帮助吗?请分享!!)
If all my clients receive the same data set (the same JSON), is there a way I could optimize even more?
如果我的所有客户端都收到相同的数据集(相同的JSON),有没有办法可以进一步优化?
I'm thinking about IP V6 'multicast' - this would minimize my bandwidth consumption by orders of magnitude - but is this practical?
我正在考虑IP V6'多播' - 这会使我的带宽消耗最小化几个数量级 - 但这是否实用?
For supporting 1 million concurrent users, for example, assuming there's an update every 10 seconds, I would need to support 100K 'hits' (or responses) per second. If the response size is 10K, the bandwidth starts becoming a big issue here: 10K * 100K * 60 * 60 * 24 --> 86 Giga per 24h.
例如,为了支持100万并发用户,假设每10秒更新一次,我需要每秒支持100K'命中'(或响应)。如果响应大小为10K,带宽开始成为一个大问题:10K * 100K * 60 * 60 * 24 - >每24小时86千兆。
There isn't really a single, focused question here (besides IPv6) - I would like to hear your thoughts, experience, and alternative approaches - I hate re-inventing the wheel, and I'm sure that the collective wisdom out there far surpasses my own.
这里没有一个单一的,有针对性的问题(除了IPv6) - 我想听听你的想法,经验和其他方法 - 我讨厌重新发明*,我相信那里的集体智慧超越了我自己。
Thanks.
1 个解决方案
#1
0
I'd like to suggest some other alternatives that are scalable, you should do cost estimations regarding your projected loads to see which is viable -
我想建议一些可扩展的其他替代方案,您应该对预计的负载进行成本估算,看看哪些是可行的 -
-
Assuming feeds may be shared across several clients (I don't know if that's relevant to your application) - use a CDN. See a description of this kind of solution here - http://tech.ftbpro.com/post/78969626647/growing-x20-without-spending-an-extra-penny-on-hosting
假设可以在多个客户端共享源(我不知道这是否与您的应用程序相关) - 使用CDN。请在此处查看此类解决方案的说明 - http://tech.ftbpro.com/post/78969626647/growing-x20-without-spending-an-extra-penny-on-hosting
-
Use a specialized messaging service as your backbone. The more prominent one in this field is PubNub.
使用专门的消息服务作为主干。这个领域中比较突出的是PubNub。
#1
0
I'd like to suggest some other alternatives that are scalable, you should do cost estimations regarding your projected loads to see which is viable -
我想建议一些可扩展的其他替代方案,您应该对预计的负载进行成本估算,看看哪些是可行的 -
-
Assuming feeds may be shared across several clients (I don't know if that's relevant to your application) - use a CDN. See a description of this kind of solution here - http://tech.ftbpro.com/post/78969626647/growing-x20-without-spending-an-extra-penny-on-hosting
假设可以在多个客户端共享源(我不知道这是否与您的应用程序相关) - 使用CDN。请在此处查看此类解决方案的说明 - http://tech.ftbpro.com/post/78969626647/growing-x20-without-spending-an-extra-penny-on-hosting
-
Use a specialized messaging service as your backbone. The more prominent one in this field is PubNub.
使用专门的消息服务作为主干。这个领域中比较突出的是PubNub。