在时间密集型应用程序中正确使用 node.js 和 Socket.IO 的其他技术?

发布于 2024-11-30 20:40:16 字数 424 浏览 1 评论 0原文

作为一个假设的例子,假设我想制作一个显示人们的 Twitter 网络的应用程序。我将提供一个 API,允许客户端查询单个用户名。该用户的前 x 条推文将被发送到客户端。然后,最初提到的每个人都会被扫描。他们的前 x 条推文将发送给客户。这个过程将递归地继续,广度优先,直到达到预定义的深度。客户端将实时接收数据,显示统计数据,例如扫描的用户数量、剩余扫描的已知用户数量以及不断增长的推文数据列表。所有处理都不复杂(少量文本的正则表达式),但许多网络请求将从单个初始请求中产生。

我真的很想要 Node.js 与 socket.io 的出色实时功能,但我觉得这是对这些技术的滥用 - 它们并不适合繁重的服务器端提升。是否有更合适的工具集来完成我想要完成的任务,或者使用这些工具来实现该目的的特定方法? Milewise 正在做类似的事情,但我认为我的应用程序会比他们的应用程序消耗更多的网络资源。

谢谢。

As a hypothetical example, let's say that I wanted to make an application that displays peoples twitter networks. I would provide an API that would allow a client to query on a single username. That user's top x tweets would be sent to the client. Then, each person that had been mentioned by the initial person would be scanned. Their top x tweets would be sent to the client. This process would recursively continue, breadth-first, until a pre-defined depth was reached. The client would be receiving the data in real time, displaying statistics such as number of users scanned, number of known users remaining to scan, and a growing list of the tweet data. None of the processing is complicated (regex of small amounts of text), but many, many network requests would be spawned from a single initial request.

I really want the fantastic realtime capabilities of node.js with socket.io, but I feel like this is an abuse of those technologies - they're not meant for heavy server-side lifting. Is there a more appropriate toolset for what I am trying to accomplish, or a particular way to use these tools to that end? Milewise is doing something similar-ish, but I think that my application would consume significantly more network resources than theirs.

Thanks.

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

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

发布评论

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

评论(1

源来凯始玺欢你 2024-12-07 20:40:16

现在您可以在网络上获得的最佳网络传输是 WebSockets,它提供持久的双向实时传输- 服务器和客户端之间的时间连接。尽管并非每个浏览器都支持它们,但 socket.io 为您提供了一些后备解决方案,但它们可能会降低与 WebSocket 相比的网络性能,如 这篇文章

在与 WebSocket 建立连接期间,客户端和服务器交换
每帧数据为 2 字节,而 http 为 8 KB
进行连续轮询时的标题。

...

减少千字节数据
减少到 2 个字节……延迟从 150 毫秒减少到 50 毫秒远远超过
边缘。事实上,仅凭这两个因素就足以让
Google 对 WebSocket 非常感兴趣。

除了网络传输之外,其他事情也可能很重要,例如如何在服务器端获取、格式化和处理数据。在 Node.js 中,大量 CPU 密集计算可能会阻塞其他异步操作的处理,因此应将此类操作分派到单独的线程或进程以防止阻塞。

The best network transport which you can get on the web now are WebSockets which offers persistent bi-directional real-time connection between server and client. Although not every browser supports them, socket.io gives you a couple of fallback solutions which may however decrease the network performance when compared to WebSockets as stated in this article:

During making connection with WebSocket, client and server exchange
data per frame which is 2 bytes each, compared to 8 kilo bytes of http
header when you do continuous polling.

...

Reducing kilobytes of data
to 2 bytes…and reducing latency from 150ms to 50ms is far more than
marginal. In fact, these two factors alone are enough to make
WebSocket seriously interesting to Google.

Apart from network transport, other things may also be important, for example how are you fetching, formating and processing the data on the server side. In node.js heavy CPU bound computations may block processing of other asynchronous operations, therefore these kind of operations should be dispatched to separate threads or processes in order to prevent blocking.

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