通过 Javascript 不断查询服务器 - 好主意吗？
我有一个小型网站，大约有 5-10 名管理员。 我已将其设置为监视每个管理员正在执行的操作（添加项目、删除项目等）。 我的管理面板中有一个列表，显示了集体管理部门之前执行的 10 项活动。 今天，我决定每 30 秒进行一次自我更新。
我的问题很简单：这样做有什么问题吗？ 我在每个请求中调用一小段文本，并且该请求可能一次仅在 3 或 4 台计算机上运行（反映了登录的并发管理员数量）。
$(document).ready(function(){
setInterval("activity()", 30000);
});
function activity() {
$("#recent_activity").load("../home/login #recent_activity .data");
}
每个请求都会生成以下内容（或类似内容 - 仅包含 10 行）。
<table>
<tbody>
<tr>
<td><p>jsampson</p></td>
<td><p>logged out</p></td>
<td><p>28 minutes 27 seconds ago</p></td>
</tr>
<tr>
<td><p>jdoe</p></td>
<td><p>logged in</p></td>
<td><p>29 minutes 45 seconds ago</p></td>
</tr>
</tbody>
</table>
I've got a small website that has about 5-10 administrators. I've set it up to monitor what each administrator is doing (adding items, removing items, etc). I had a list within our admin-panel that shows the previous 10 activities performed by the collective administration. Today, I decided to make this self-updating every 30 seconds.
My question is simple: is there any problem doing this? I'm calling a small bit of text with each request, and the request is likely only running on 3 or 4 computers at a time (reflecting the number of concurrent-administrators logged in).
$(document).ready(function(){
setInterval("activity()", 30000);
});
function activity() {
$("#recent_activity").load("../home/login #recent_activity .data");
}
Produces the following (or similar - only with 10 rows) with each request.
<table>
<tbody>
<tr>
<td><p>jsampson</p></td>
<td><p>logged out</p></td>
<td><p>28 minutes 27 seconds ago</p></td>
</tr>
<tr>
<td><p>jdoe</p></td>
<td><p>logged in</p></td>
<td><p>29 minutes 45 seconds ago</p></td>
</tr>
</tbody>
</table>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
每 30 秒 3-4 个用户根本不算多。 按照这个速度，即使有 300 个用户也根本不算什么。
您可能需要检查以下问题：
您可以也缓存它，并且建议特别是如果生成页面的查询计算量很大，但当然要考虑到您希望在最新内容中出现什么样的滞后正在显示。
3-4 users every 30 seconds isn't very much at all. Even 300 users at that rate wouldn't be much at all.
You may want to check into these questions:
You can cache this as well, and it would be advisable especially if the query to generate the page is computationally heavy, but of course take into account what kind of lag you want in the most recent content being displayed.
您应该缓存此内容并且每 30 秒更新一次缓存。
You should cache this and only update the cache every 30 seconds.
不，应该没有任何问题。 我每隔 1 分钟对我在公司内联网门户上编写的通知系统执行相同的操作。 老实说，任何网络服务器都应该能够处理这个问题。
这实际上并不比他们更糟糕（事实上，明显更好），比如说，每 30 秒刷新一次浏览器……考虑到数据传输要小得多，这可能比刷新好 10-20 倍。 .. 或者，大约与每 5-10 分钟刷新一次的带宽相同。 :-)
No, there shouldn't be any problem at all. I do the same thing at 1 minute intervals for a notification system I wrote on my company's intranet portal. Any web server should be able to handle this, honestly.
It's really no worse (in fact, significantly better) than them, say, refreshing their browser every 30 seconds... Considering the significantly smaller data transfer, it would likely be something on the scale of 10-20 times better than refreshing it... or, about the same bandwidth of refreshing once every 5-10 minutes. :-)
我认为完全没有问题。 运行规模更大的站点（例如 Betfair）每个连接的客户端每分钟使用数百个 xhr 调用。
显然他们拥有更大的硬件基础设施，但浏览器处理得很好。
我的网站使用较小的间隔，并且可以扩展到从单个网络服务器运行的数百个并发用户。
No issue at all in my opinion. Sites that run on a much bigger scale (Betfair for instance) use hundreds of xhr calls per minute per connected client.
Obviously they have much bigger hardware infrastructures but the browser copes fine.
I have sites that use a smaller interval and they scale to a few hundred concurrent users running from a sinlge webserver.
我认为这不会造成问题。
I don't think it would pose a problem.
我想说这主要取决于查询的成本。
虽然现在用户数量很少，但会一直这样吗？
I would say it would primarily depend on how expensive that query is.
Although it is a low number of users now, will it always be so?
正如 altCognito 指出的那样——由此产生的网络流量不太可能成为问题。
我唯一要检查的是所需的数据库负载是否会成为问题。 IE。 如果这是由需要一些时间运行的查询提供的，则会导致问题。 如果是这种情况，我建议向数据添加一些缓存，或者在内存中而不是数据库中维护数据（仅在启动时从数据库加载，并将内容添加到服务器内存列表中，如下所示）它们发生了）。
As altCognito pointed out -- the web traffic from this isn't likely to be an issue.
The only thing I'd check is whether the database load required for this will be an issue. Ie. if this is fed by a query that takes some time to run, it'll cause problems. If that's the case though, I'd recommend adding some caching to the data, or maintaining the data for this in memory instead of the DB (only loading from the DB on startup, and adding things to this in-server-memory list as they happen).
权衡它与替代方案。 如果每个用户每 30 秒刷新一次页面，加载整个页面，那么服务器端处理量和产生的流量将比仅仅刷新“有趣的部分”大得多。
这就是 AJAX 的诞生目的。
Weigh it against the alternative. If each user was refreshing the page every 30 seconds, loading the whole page, the amount of server side processing and traffic generated would be much greater than just refreshing the "interesting parts."
This is what AJAX was made for.
您是否看到了 Google Wave 预览版...？ 对于这么小的数字来说，这不是问题，特别是当管理员知道这一点时。 （这并不是说您给某些访问者的 CPU 或移动互联网连接带来了一些负担。）
Did you see the Google Wave preview...? For such a small number this is not an issue, especially as the administrators will know about this. (It's not like you're putting some burden on some visitor's CPU or mobile internet connection.)
许多用户不会导致您的服务器瘫痪。
如果你真的关心性能，我会给你两个建议：
对历史数据使用固定日期并计算客户端上的相对时间，这将允许您缓存历史数据。
{"user":"jsampson","action":"logged out","date":"20090622T170822"}That many users are not going to bring down your server.
If you are really concerned about performance, I will give you 2 advice:
Use fixed date for history data and compute the relative time on the client, it will allow you to cache the history data.
{"user":"jsampson","action":"logged out","date":"20090622T170822"}是的，这应该不成问题。
话虽这么说，如果您担心发送回的数据量，您始终可以让调用发送回一个简单的标志（如果有新数据），然后在这种情况下获取数据。
但是，是的，有了这么多的用户，你应该不会有任何问题。 我经常使用一个基于 RoR 的自定义留言板，使用类似的技术来查看线程是否在您阅读时已更新，并且有超过 100 个用户同时访问它，没有任何问题。
Yeah, this shouldn't be a problem in the slightest.
That being said, if you're concerned about the amount of data that's sent back you can always make the call send back a simple flag IF there's new data and then go fetch the data if that's the case.
But yeah, with that number of users you shouldn't have any problems. A custom RoR-based message board I frequent uses a similar technique to see if threads have been updated while you're reading it and it has upwards of 100 users hitting it concurrently without any problem.
有几种不同的方法可以模拟通过 HTTP 进行的服务器推送。 这种技术最近有了一个奇特的名字：Comet。
如果您的服务器配置允许无限期运行脚本，您可以使用 iframe 来实现面板并使用分块传输（例如通过 PHP 的
flush()）来创建持久 HTTP 连接。 如果连续消息之间的时间间隔很短，则这种解决方案应该具有最小的开销。 对于长间隔，客户端轮询更可取，因为无需维护 TCP 连接。There are several different ways to emulate server push over HTTP. Such techniques recently got a fancy name: Comet.
If your server configuration allows for indefinitely running scripts, you could use an iframe to implement the panel and use chunked transfers (e.g. via PHP's
flush()) to create a persistent HTTP connection. Such a solution should have the least overhead if the time interval between consecutive messages is short. For long intervals, client-side polling is preferable as no TCP connection has to be maintained.我认为你所做的很棒。
如果我正在做这个项目，我会从你所拥有的开始，并添加一个 setTimeout() 事件来增加每秒显示的分钟/秒数。
用户会认为显示是实时的，他们可能永远不会刷新页面。
每 30 秒更新一次的危险在于，有些人每次将注意力转向“最新”时，都会条件反射地点击刷新以获取“最新”内容。
还可以考虑专门标记任何时间少于五分钟的内容。 以及登录与注销的颜色编码。 人们将更容易“扫描”，因为他们无需阅读所有文本即可找出更改。
I think what you did is great.
If I were doing this project, I'd start with what you have and add a setTimeout() event to increment the minutes/seconds display every second.
The users would perceive the display to be real-time, and they'd probably never hit the page refresh.
The danger with updating only every 30 seconds is some people will reflexively hit refresh for "the latest" every time they turn their attention toward it.
Also consider specially marking anything with a time less than five minutes. And color coding logged in versus logged out. It'll be easier for people to "scan" because they'll be able to pick out changes without reading all the text.