扭曲：在反应器过载的情况下优雅地降低性能？
是否可以以某种方式“检测”反应堆过载并开始丢弃连接，或拒绝新连接？如何才能避免反应堆完全超载而跟不上呢？
Is it somehow possible to "detect" that the reactor is overloaded and start dropping connections, or refuse new connections? How can we avoid the reactor being completely overloaded and not being able to catch up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我正确理解 Twisted Reactors，它们不会并行化所有内容。已排队的所有操作都会被安排并一一完成。
一种解决方法是使用自定义
addCallback来检查已注册的回调数量，并在必要时删除。If I understand Twisted Reactors correctly, they don't parallelize everything. Whatever operations have been queued is scheduled and is done one by one.
One way out for you is to have a custom
addCallbackwhich checks for how many callbacks have been registered already and drop if necessary.没有简单的方法，但这里有一些建议： http://www .mail-archive.com/[电子邮件受保护]/msg00389.html
No easy way, but here's some suggestions: http://www.mail-archive.com/[email protected]/msg00389.html
我会按照协议处理这个问题。在实际服务需要时进行限制，而不是在您认为需要时进行限制。我不会担心有多少回调正在等待反应器滴答，而是担心 HTTP 请求（例如）需要多长时间才能完成。等待反应器的操作数量可能是一个实现细节 - 例如，如果一种访问模式以长 DeferredList 上的回调结束，而另一种访问模式具有更线性的回调链，则响应时间可能不会不同，即使回调的数量是。
这可以通过保存完成逻辑操作（例如服务 HTTP 请求）的时间度量来完成。这样做的优点是它可以在问题发生之前为您提供重要信息。
I would approach this per protocol. Throttle when the actual service requires it, not when you think it will. Rather than worrying about how many callbacks are waiting for a reactor tick, I'd worry about how long the HTTP requests (for example) are taking to complete. The number of operations waiting for the reactor could be an implementation detail - for example, if one access pattern ended up with callbacks on long DeferredLists, and another had a more linear chain of callbacks, the time to respond might not be different even though the number of callbacks would be.
This could be done by keeping metrics of the time to complete a logical operation (such as servicing a HTTP request). An advantage of this is that it gives you important information before a problem happens.