HTTP 在大型 Web 应用程序中保持活动状态

发布于 2024-11-09 12:23:41 字数 177 浏览 0 评论 0 原文

我有一个通过 IIS 7.0 部署的 Web 应用程序。该应用程序可供大量用户访问并处理大量数据..我的问题是关于默认情况下设置为 true 的 HTTP Keep-Alive 选项。

将 HTTP Keep-Alive 设置为 false 或 true 是更好的方法吗?

如果是真的,是使用超时的好方法吗?

I have a web application deployed over IIS 7.0. the application is accessible by large number of users and manipulates large data ..my question is concerning the HTTP Keep-Alive option which is set to true by default.

is it a better approach to set the HTTP Keep-Alive to false or true.

in case of true is the good approach to use time out?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

耳钉梦 2024-11-16 12:23:41

KeepAlive 通常应该用于处理紧随 HTML 请求的请求。假设第一次访问您的网站时,我得到一个包含 5 个 css、5js 和 25 个图像的 HTML 页面,我将使用仍然有效的 HTTP 连接来请求这些内容(嗯,取决于浏览器,我可能会使用3 个连接来加速这些事情)。

为了处理这个事实,我们通常使用2s或3s的Keepalive。保持活动时间较长意味着连接正在等待用户可能请求的下一页。这可能是一种有效的思维方式,下次用户想要一个页面时,我们将避免浪费建立 HTTP 连接的时间(这可能是请求/响应时间的最长部分)。但对于您的服务器来说,这意味着服务器处理的大多数 HTTP 连接都什么都不做。您将达到 MaxConnection(W3SVC/MaxConnections,默认值为 10,可笑),但连接不执行任何操作。真的很糟糕。如此长时间的保持活动需要大型网络服务器,并且仅当您的应用程序确实需要它时才应该使用它。

如果您在“经典网站”中使用 Keepalive,您必须更改连接超时(默认为 2 分钟)。在 Apache 中,您将有 2 个设置,一个 keepalive tiemout(默认为 5 秒)和一个连接超时(2 分钟)。在 IIS 中,超时设置似乎适用于两者。所以不要将其设置为 2 秒(客户端发送请求的速度非常慢将会超时),但 10 秒之类的值可能就足够了。现在的一种应对措施是禁止 Keep-Alive,并让浏览器打开更多连接。另一种应对方法是使用现代 Web 服务器(例如 nginx 或 cherokee),它以比 Apache 或 IIS 更优雅且无资源的方式处理保持活动连接。

即使不使用Keepalive,客户端超时等待2分钟是什么原因?它肯定太高了,降低这个值到 60 左右。

然后您应该检查与超时相关的几个设置(ConnectionTimeout、HeaderWaitTimeout、MinFileBytesPerSec)以及 注册表中的性能设置

KeepAlive should normally be used to handle the requests that immediately follow an HTML request. Let's say on the first visit to your site I get an HTML page with 5 css, 5js and 25 images, I will use my HTTP connection which is still alive to request these things (well, depends on the browser, I'll maybe use 3 connection to speed up these things).

To handle this fact we usually use a Keepalive of 2s or 3s. Having a longer keepalive means the connection is waiting for the next page that the user may request. This may be a valid way of thinking, next time the user will want a page, we'll avoid to loose time establishing HTTP connection (and this can be the longest part of the request/response time). But for your server that mean most of HTTP connection that are handled by the server are doing... nothing. And you will reach your MaxConnection (W3SVC/MaxConnections with a ridiculous default to 10), with connections doing nothing. Really Bad. So long keep-alive needs big webservers and should be used only if your application really needs it.

If you use Keepalive in a 'classical website' you must change the connection timeout (by default 2min). In Apache you would have 2 settings, a keepalive tiemout (5s by default) and a connection timeout (2min). In IIS seems the timeout settings is used for both. So do not set it to 2s (a client really slow in sending his request will timeout), but something like 10s is maybe enough. Now one response is to disallow Keep-Alive, and make the browser opening more connections. Another response is to use a modern webserver (like nginx or cherokee for example) which handles keep-alive connection in a more elegant and resource-free way than Apache or IIS.

Even if you do not use Keepalive, what's the reason of waiting 2 minutes for a client timeout? it's is certainly too high, decrease this value to something like 60s.

Then you should check several settings related to timeout (ConnectionTimeout, HeaderWaitTimeout, MinFileBytesPerSec) and this nice response on performances settings in the registry.

岛歌少女 2024-11-16 12:23:41

本文将带来更多见解,并且不要忘记查看“我们如何修复它?”部分
http://mocko.org.uk/b/ 2011/01/23/http-keepalive-considered-harmful/

This article will bring more insight and don't forget to check the "How do we fix it?" section
http://mocko.org.uk/b/2011/01/23/http-keepalive-considered-harmful/

吹泡泡o 2024-11-16 12:23:41

我认为让所有用户连接并不是一个好主意。

因为:

  1. 用户只能打开您的网站,但不能使用它 - 为什么我们要长时间保持连接?
  2. 很难保持大量连接(更多内存)

使用连接超时(最多 5 分钟就可以了)

但是:如果您的应用程序是实时聊天 - 您应该保持所有连接处于活动状态。这种方式最好使用 Ajax Long Polling Request + Node JS + 一些快速的 nosql db 来存储聊天消息。

I think that it's not a good idea to get all users connected.

Because of:

  1. User just can open your site, but not use it - why we shoud keep connection for long time?
  2. It's hard to keep much connection (more memory)

Use connection time-out (max 5 min will we ok)

BUT: if your application is a live chat - you should kepp alive all connection. In this way better to use Ajax Long Polling Request + Node JS + some fast nosql db to store chat messages.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文