因此，收集一些经验数据，例如：对于多少次使用，此轮询负载变得重要？进行一些负载测试，不仅是轮询，还包括这些用户正在执行的其他工作。他们肯定不只是进行轮询，他们还在做其他也会加载 MySQL 的事情。这什么时候嘎吱嘎吱响？到那时，由此产生的收入会让您购买更多容量吗？或者您是否有信心不同的架构可以解决该问题。换句话说，你有一个现实的“出局”吗？
For some number of users it must eventually put on a "heavy" load, but that's not a "bad thing".
For any application, architected in any way, there will be some point at which some part of the infrastructure creaks. That's not an intrinsic reason to adopt some more sophisticated solution (and move the bottleneck elsewhere).
So gather some empirical data, such as : for what number number of uses does this polling load become significant? Do some load tests, not just of polling but of the other work these users are doing. They surely are not just polling they are doing other stuff that will also load MySQL. When does this creak? At that point would the resulting revenues allow you to buy more capacity? Or would you have confidence that a different architecture would fix the problem. In other words do you have a realistic "out"?
My guess is that if polling becomes an issue you have some good intermediate solutions such as caching, or reducing the polling frequency, in addition to the possibility of introducing Comet. And so it's reasonable to start with your simple polling strategy.
发布评论
评论（1）
对于某些数量的用户来说，它最终必然会带来“沉重”的负载，但这并不是一件“坏事”。
对于任何应用程序，无论以任何方式构建，都会有某个时刻基础设施的某些部分出现问题。这并不是采用一些更复杂的解决方案（并将瓶颈转移到其他地方）的内在原因。
因此，收集一些经验数据，例如：对于多少次使用，此轮询负载变得重要？进行一些负载测试，不仅是轮询，还包括这些用户正在执行的其他工作。他们肯定不只是进行轮询，他们还在做其他也会加载 MySQL 的事情。这什么时候嘎吱嘎吱响？到那时，由此产生的收入会让您购买更多容量吗？或者您是否有信心不同的架构可以解决该问题。换句话说，你有一个现实的“出局”吗？
我的猜测是，如果轮询成为一个问题，除了引入 Comet 的可能性之外，您还有一些好的中间解决方案，例如缓存或降低轮询频率。因此，从简单的轮询策略开始是合理的。
For some number of users it must eventually put on a "heavy" load, but that's not a "bad thing".
For any application, architected in any way, there will be some point at which some part of the infrastructure creaks. That's not an intrinsic reason to adopt some more sophisticated solution (and move the bottleneck elsewhere).
So gather some empirical data, such as : for what number number of uses does this polling load become significant? Do some load tests, not just of polling but of the other work these users are doing. They surely are not just polling they are doing other stuff that will also load MySQL. When does this creak? At that point would the resulting revenues allow you to buy more capacity? Or would you have confidence that a different architecture would fix the problem. In other words do you have a realistic "out"?
My guess is that if polling becomes an issue you have some good intermediate solutions such as caching, or reducing the polling frequency, in addition to the possibility of introducing Comet. And so it's reasonable to start with your simple polling strategy.