🏆 基准测试

如上所示：Soketi 真的很快！

在上述基准测试方案中，有 500 个用户闲置，每秒接收 1 条信息，同时 500 个用户在 5 秒后主动连接和断开，实现了仅有6毫秒的内部延迟。

AWS t3 （无突发） 套件

基准测试是在 AWS 的 t3.small实例上进行的（禁用了 T3 Unlimited 以避免突发），2 vCPU 2 GB和千兆网络，位于 欧洲法兰克福 地区。客户端位置和服务器位置之间的 ping 值平均为 42 ms。

网络开销是通过减去两次 ping 来得出的，因为客户机到服务器广播信息一次，然后再从服务器到客户机再返回一次。

要计算服务器处理和分发收到的信息所需的内部延时，你可以使用以下公式：

内部延时 = 计算出的延时 - (网络 ping 值 * 2)

在这种情况下，soketi 处理一条消息所需的时间（不包括网络开销）：

内部延时 = 90 - (42 * 2) = 90 - 84 = 6 ms

对于一个 2 vCPU 2 GB 的实例，服务器需要 6ms 来分发 500 个并发用户的信息，此外还有 100 到 500 个逐步增加的用户之间的连接。正如你所看到的，soketi 很容易处理这种负载情况。

ARM 性能

在同样的情况下，使用 AWS 的Graviton实例（t4g），使用 Docker ARM 构建的性能 高出30%。

性能注意事项

在部署 soketi 时，你可能还需要考虑额外的开销：

• 网络开销，如本基准测试中包括的开销，或在用 Redis 进行水平扩展时的开销。

• SSL/TLS 的开销，这是 SSL/TLS 固有的特点。

• 这些基准测试不利用队列。当使用队列来处理消息时，需要额外的计算能力来完成 webhooks。

• 这些基准测试没有考虑到其他非广播调用的 HTTP 请求，因为这些基准只使用 HTTP API 来发布消息。

当在要求非常高的应用中把 soketi 部署到生产中时，请考虑以下建议：

水平扩展

soketi 原生 使用Redis Pub/Sub进行水平扩展。这可能会增加内部 Redis 通信的开销；然而，由于你可以水平扩展你的 soketi 服务器，总的可扩展性得到了提高。

此外，通过在全局 Redis 网络内将 soketi 实例部署在离 Redis 读取副本更近的地方，你可以确保低延迟。

在离用户更近的地方部署

在大多数应用中，造成 soketi 开销的最大因素是网络延迟。考虑在离用户较近的地方部署，以获得低于 100 毫秒的延迟，并开发一个适当的应用网，以确保在全局范围内与 Redis 进行良好的横向扩展。