AJAX 聊天在过载和变慢之前能够在专用服务器上处理多少成员？答案

【问题标题】：How many members will an AJAX chat be able to handle on a dedicated server before it overloads and becomes slow?AJAX 聊天在过载和变慢之前能够在专用服务器上处理多少成员？
【发布时间】：2011-09-08 16:49:52
【问题描述】：

专用服务器的详细信息（网站启动时）如下：

操作系统：Linux CentOS

CPU：Intel® Pentium 4 - 3.0 GHz

内存：2 GB

存储：2 个 120 GB 硬盘

带宽：每月 500 GB

AJAX 聊天是自定义编码的。它通过向数据库发送和接收 Javascript 命令来运行，然后对它们进行评估。

聊天刷新率可能在 250 毫秒左右，但此处的答案可能会改变决定。

【问题讨论】：

一根绳子有多长？ ;-) 尽管你已经给出了具体细节，但我怀疑任何人都可以为你回答这个问题。您必须对给定的配置进行负载测试。如果您想要估计，您必须展示您的代码（主要是服务器端代码）并给出典型消息和同时连接的客户端数量的概念。但即便如此，估计的误差范围也会很大，几乎毫无意义。
为什么不使用 node.js 而不是在整个聊天过程中使用 db？聊天的数量将取决于您的数据库能够处理的读/写数量。 300ish 同时听起来像这样的应用程序的容量（它基于数据库的读/写将成为瓶颈的假设——这意味着硬盘子系统实际上会限制正在发生的事情）。
@T.J. Crowder 我还没有真正编写过聊天室的代码，不过我希望能找到提高性能的方法。 @Michael J.V. 感谢您的建议，我可能会尝试您的建议而不是数据库。这个想法能够处理多少额外的容量？
我不确定您运行聊天框的原因以及平均有多少用户，但老实说，我认为您的问题可以忽略不计。另一方面，考虑到带宽和易用性，我确实发现 WebSockets 比每秒多次调用 AJAX 更有用。
@MichaelJ.V.我不是这个主题的专家并且偶然发现了这个问题，因为我也在实现同样的事情，我使用 SSE（服务器发送的事件）作为聊天应用程序，它似乎工作正常。我正在使用 PHP-MySql。我的服务器有 8Gb 内存和足够好的处理器。我想知道这是否是个好主意？

标签： php javascript mysql ajax chat

【解决方案1】：

如果您想实现基于浏览器的聊天应用程序，该应用程序将在相对便宜的服务器上运行，并且能够为大量用户（例如，一次 500 个）提供服务而不会崩溃 - 您的方法无效。

原因：使用 DB 将 JS 发送给评估代码的客户并不安全。它也很贵。这也意味着每一行聊天，您都需要至少调用一次数据库。这意味着 RDBMS 需要大量 I/O。

如果我是你，我会查看Node.js。

Node.js 允许您使用 JavaScript 编写聊天服务器。 JS 本身不是由浏览器执行，而是由服务器执行。它非常 I/O 效率高。它也很简单，可以让非专业程序员创建适当的聊天应用程序。

【讨论】：

如果没有数据库（不管是 RDBMS 还是 NoSQL）后端，您将无法扩展

【解决方案2】：

使用 php 作为聊天服务器并不是一个好主意。轮询会给服务器带来过多不必要的负载并且不能很好地扩展。在我看来，您应该重新考虑整个架构。

轮询不利于聊天 - 请改用 Comet（长轮询）
使用 comet，您将需要能够处理数千个并发连接的快速 HTTP 服务器 - 使用 NGINX
PHP 不是聊天应用程序的好解决方案 - 类似进程的非阻塞解决方案要好得多 - 看看 Tornado 和他们的聊天示例
从现在开始，您必须决定是否需要扩展 - 如果不需要，您可以在 tornado 之上编写单线程服务器并将所有数据存储在内存中 - 当然，您需要删除不需要的旧数据。如果您需要扩展，请选择像 MongoDB 这样的快速可扩展数据存储 - 您必须轮询数据库 - 但对于连接到单个龙卷风实例的所有客户端，这将是单个查询 - 不是针对每个客户端

Facebook 使用（或仍在使用）这种架构（使用 MySQL 后端）以满足他们的需求

【讨论】：

你说轮询不利于聊天，那么你建议 Comet 但 Comet 实际上使用轮询来聊天。有点矛盾，你不觉得吗？否则 - 我同意使用 NGINX 作为 HTTP 服务器。
Comet 使用长轮询，这与标准轮询非常不同。我想说它们的工作方式、它们产生的数据库查询数量和它们发出的 http 请求数量存在巨大差异。从概念上讲，它们是完全不同的东西——标准轮询是“拉架构”（客户端定期向服务器询问数据），彗星是“推送架构”（服务器决定何时有数据提供给客户端，然后将其推送到客户端）
并非如此，为了让基于 Comet 的应用程序检索数据 - 客户端必须专门请求数据。没有实际的推动，一切都是模拟的。如果不是这样，WebSocket 协议就不会被定义和实现，那是浏览器唯一真正的全双工通信协议。其他一切都在伪装某种推送机制，无论是隐藏的 iframe 还是其他 - 底线是客户端（浏览器）定期从服务器请求资源。
模拟但客户端不必定期从服务器请求数据。在彗星中，它发出无限（或足够长）超时的 AJAX 请求，服务器决定何时返回该请求的数据。当然，在完成请求后，客户端必须启动另一个，但是：让我们看一下：1000 个客户端，200 毫秒标准轮询与彗星（使用 200 毫秒服务器端数据库轮询），5 秒时间。标准轮询：25000 个 HTTP 请求，25000 个数据库查询。 Comet：1000-25000 个 HTTP 请求（取决于实际数据），25 个数据库查询（少 1000 倍！！）
我不是在争论什么更有效，最重要的是，这都是依赖于 request-get 数据方案的虚假全双工通信，最终 - 是长轮询，不管无论您将其称为 Comet、长轮询或 ajax 聊天，还是您喜欢的任何流行语。有更好的实现（Node.js 或 WebSockets 协议）被证明比基于 Comet 的应用程序更出色。