基准测试
🏆 基准测试
如上所示: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 进行良好的横向扩展。
推荐文章: