专用服务器每秒发送多个请求是否现实?

时间:2014-04-17 20:09:46

标签: networking max scalability

TL; DR

(专用)Web服务器是否适合每秒向其他服务器发送许多请求(当然是获得所述服务器的许可)?


我这样做纯粹是为了节省自己花费很长时间来实现一个不起作用的想法,因为我希望人们对此有更深入的了解。

我正在开发一种解决方案,允许客户端监控其服务器的状态。我需要不断(24/7)从这些服务器获取更新的日志。不幸的是,我只能将最后 150个条目添加到他们的日志中。这意味着对于繁忙的客户端,我需要更多地轮询他们的服务器。

我正在尝试使我的解决方案具有可扩展性,以便如果它获得了大量客户,我就不需要担心自己重写它了,所以我的基准是 1000个客户,因为我认为这是一个现实的上限。

如果我有1000个客户端,并且我需要每次轮询他们的服务器,让我们给它一个数字,两分钟,我将每秒向超过8台服务器发送请求。返回的结果平均约为15,000个字符,但它可能会或多或少。

请记住,此服务器还需要处理访问它的客户端以查看其服务器信息,因此需要无滞后。

我一直在考虑的一些优化,我可能需要相对较早地实施:

  • 仅询问50个日志项。如果我们找到一个已经存储的(它们按时间顺序返回),我们可以终止。如果没有,我们会抛弃另一个100的请求。这应该会减少大约3/5的流量。
  • 检测哪些服务器获得更多流量并且不太常见地请求他们的日志(即,如果服务器每小时只获得10个记录事件,我们不想每隔几分钟要求150个)

我基本上问的是,每秒发送这么多请求是否被认为是坏事以及我未来的主机是否可能开始提问或尝试限制我的服务器。我的目标是为前几个客户分享,然后如果它变得足够受欢迎,请转到专用服务器。

我知道这有一定程度的意见启用,所以我担心它可能是关闭的候选人,但我确实觉得答案中有一定程度的事实性应该使它成为一个好的问题。

我不确定是否有网络SE,或者这可能更适合SuperUser或其他什么,但感觉就是这样。如果此处不合适,请尽快给我发表评论,我会将其删除并发布到建议的新位置。

1 个答案:

答案 0 :(得分:1)

您可能想了解C10K Problem。本文比较了几种I / O策略。使用非阻塞I / O处理多个连接的一定数量的线程是最好的方法imho。

关于您的具体项目,我认为轮询有限数量的日志项是个坏主意。当日志活动达到峰值时,您将错过潜在的关键数据,尤其是在应用优化时。

如果您监控的客户端将新的日志项目推送到您的服务器,那将会更好。这样你就不会错过重要的事情。

我不熟悉ASP.NET的性能,所以如果单个专用服务器足够,我就无法回答。特别是因为我不知道你的服务器的规格是什么。使用合理的强大服务器应该是可能的。如果结果不够,则应将项目分布在多个服务器上。