Ajax“有新内容吗？” 如果是，则更新页面” - 如何在不破坏服务器的情况下做到这一点？
这是一个简单的 JavaScript 例子，它不断地询问“到了吗？” 就像一个四岁的孩子开车一样。但是，就像父母一样，如果你这样做太频繁，或者同时有太多孩子，服务器就会在压力下崩溃。
你如何解决网页的问题每隔 5 秒查找一次新内容并允许更多访问者？
It's a simple case of a javascript that continuously asks "are there yet?" Like a four year old on a car drive.. But, much like parents, if you do this too often or, with too many kids at once, the server will buckle under pressure..
How do you solve the issue of having a webpage that looks for new content in the order of every 5 seconds and that allows for a larger number of visitors?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
stackoverflow 以某种方式实现了这一点，但不知道如何实现。
更标准的方法确实是每隔几秒查找新内容的 javascript。
更高级的方法是使用 push-like 技术，通过使用 Comet 技术（长轮询等）。 该链接下有很多有趣的内容。
我仍在等待自己使用它的好机会...
哦，这是来自 stackoverflow 的关于它的链接：
是否有某种方法可以从Web 服务器到浏览器？
stackoverflow does it some way, don't know how though.
The more standard way would indeed be the javascript that looks for new content every few seconds.
A more advanced way would use a push-like technique, by using Comet techniques (long-polling and such). There's a lot of interesting stuff under that link.
I'm still waiting for a good opportunity to use it myself...
Oh, and here's a link from stackoverflow about it:
Is there some way to PUSH data from web server to browser?
在 Java 中，我使用了采用 Comet 技术的 Ajax 库 (DWR) - 我认为您应该使用它在 PHP 中搜索库。
这个想法是，服务器正在发送一个很长的 Http 响应，当它有东西要发送到客户端时，它会结束它并发送带有更新数据的新响应。
使用它客户端不必每 x 秒 ping 服务器一次来获取新数据 - 我认为它可以帮助你。
In Java I used Ajax library (DWR) using Comet technology - I think you should search for library in PHP using it.
The idea is that server is sending one very long Http response and when it has something to send to the client it ends it and send new response with updated data.
Using it client doens't have to ping server every x seconds to get new data - I think it could help you.
您可以根据客户端数量设置轮询时间变量。 用你的比喻，孩子问“我们到了吗？” 司机回答“不，但也许一个小时后”。 值得庆幸的是，Javascript 不是一个顽固的孩子，所以你可以确定他在那之前不会打扰你。
You could make the poll time variable depending on the number of clients. Using your metaphor, the kid asks "Are we there yet?" and the driver responds "No, but maybe in an hour". Thankfully, Javascript isn't a stubborn kid so you can be sure he won't bug you until then.
您可以考虑开始每 5 秒轮询一次，但一段时间后开始增加轮询间隔时间 - 可能达到某个上限（1 分钟、5 分钟 - 任何看起来最适合您使用的时间）。 增加不一定是线性的。
更复杂的旋转（可以结合 Monzee 的建议，根据客户端数量进行变化）是允许服务器决定下一次轮询之前的时间间隔。 然后，服务器可以随着时间的推移增加间隔，您甚至可以动态更改算法，或者响应网络负载。
You could consider polling every 5 seconds to start with, but after a while start to increase the poll interval time - perhaps up to some upper limit (1 minute, 5 minute - whatever seems optimal for your usage). The increase doesn't have to be linear.
A more sophisticated spin (which could incorporate monzee's suggestion to vary by number of clients), would be to allow the server to dictate the interval before next poll. The server could then increase the intervale over time, and you can even change the algorithm on the fly, or in response to network load.
您可以查看 python 中的 'Twisted' 框架。 它是事件驱动的网络编程框架，可能会满足您的需求。 它可用于从服务器推送消息。
You could take a look at the 'Twisted' framework in python. It's event-driven network programming framework that might satisfy what you are looking for. It can be used to push messages from the server.
也许您可以将查询发送到真正的简单脚本，该脚本不需要进行真正的数据库查询，而仅使用简单的时间戳来判断是否有任何新内容。
然后，如果答案为真，您可以进行真正的查询，其中服务器必须做真正的工作！-)
Perhaps you can send a query to a real simple script, that doesn't need to make a real db-query, but only uses a simple timestamp to tell if there is anything new.
And then, if the answer is true, you can do a real query, where the server has to do real work !-)
我将有一个调用数据库的实例，如果存在更新的时间戳，则将该新时间戳放入应用程序变量中。 然后让所有会话检查该应用程序变量。 或类似的东西。 这样一来，只有一个实例正在调用 sql-server，并且客户端的数量并不重要。
我还没有尝试过这个，这只是头顶上的第一个想法，但我认为兑现时间戳并让客户端检查兑现是一种方法，以及如何实现兑现（sql-server-cashe，应用程序变量等）我不知道什么是最好的。
I would have a single instance calling the DB and if a newer timestamp exists, put that new timestamp in a application variable. Then let all sessions check against that application variable. Or something like that. That way only one innstance are calling the sql-server and the number of clients does'nt matter.
I havent tried this and its just the first idéa on the top of the head but I think that cashe the timestamp and let the clients check the cashe is a way to do it, and how to implement the cashe (sql-server-cashe, application variable and so on) I dont know whats best.
关于 SO 是如何做到的，请注意，它不会连续检查新答案，只有当您在“您的答案”框中键入内容时才会检查新答案。
那么，关键是首先执行计算成本低的操作来清除常见的“无需更新”情况（例如，输入新答案或检查时间戳），然后再启动更昂贵的过程来实际检索任何更改。
或者，根据您的应用程序，您可以通过优化更改发布机制来解决此问题。 例如，也许可以将更改（或其摘要）放入 RSS 源并让客户观看该源而不是真正的应用程序。 我们可以假设这将是相当高效的，因为这正是 RSS 设计和优化的目的，此外，它还有一个额外的好处，即使您的应用程序与世界其他地方的互操作性大大增强，而无需花费很少的成本或无需花费任何成本。你。
Regarding how SO does it, note that it doesn't check for new answers continuously, only when you're typing into the "Your Answer" box.
The key then, is to first do a computationally cheap operation to weed out common "no update needed" cases (e.g., entering a new answer or checking a timestamp) before initiating a more expensive process to actually retrieve any changes.
Alternately, depending on your application, you may be able to resolve this by optimizing your change-publishing mechanism. For example, perhaps it might be feasible for changes (or summaries of them) to be put onto an RSS feed and have clients watch the feed instead of the real application. We can assume that this would be fairly efficient, as it's exactly the sort of thing RSS is designed and optimized for, plus it would have the additional benefit of making your application much more interoperable with the rest of the world at little or no cost to you.
我相信该方法应该基于服务器端套接字和客户端 ajax/comet 的组合。 例如：
假设一个聊天应用程序有多个登录用户，并且每个用户都通过对服务器端侦听器脚本的慢加载 AJAX 调用进行侦听。
无论哪种浏览器获取刚刚输入的数据，都会通过对编写器脚本的 ajax 调用将其提交到服务器。 该服务器更新数据库（或存储系统）并将套接字写入发布到指定的侦听器脚本。 然后，后者获取新数据并将其发送回客户端浏览器。
现在我还没有写这个，现在我不知道浏览器对两个并发连接的限制是否/如何破坏了上述逻辑。
非常感谢在这里聆听任何有想法的人。
作为
I believe the approach shd be based on a combination of server-side sockets and client-side ajax/comet. Like:
Assume a chat application with several logged on users, and that each of them is listening via a slow-load AJAX call to the server-side listener script.
Whatever browser gets the just-entered data submits it to the server with an ajax call to a writer script. That server updates the database (or storage system) and posts a sockets write to noted listener script. The latter then gets the fresh data and posts it back to the client browser.
Now I haven't yet written this, and right now I dunno whether/how the browser limit of two concurrent connections screws up the above logic.
Will appreciate hearing fm anyone with thoughts here.
AS