作为我之前的问题的后续跟进,Redis如何实现高吞吐量和高性能？
我有以下问题
我已经看到Redis在行动,并对其能力印象深刻.想要更多地了解这种魔力.我已经看到,当Redis盒和查询盒更接近时,即使在高QPS(1kps)时,响应时间也是5ms.当它们在地理上更远时(数据中心与不同的数据中心相同),响应时间可达50毫秒.这只是网络延迟还是Redis必须保持一些开销,直到整个数据被刷新.
连接数可以影响Redis吞吐量吗？想象一下,Redis能够以500微秒的速度响应每个请求.并且假设1000个不同的客户端连接在给定实例上有1000个不同的请求.最后一个请求是否需要500muSec*1000 = 500ms？
响应大小可以在这里产生影响吗？想象一下,每个响应的大小为100 KB,Redis上的TCP连接必须等到最后一个数据包交付,如果网络连接速度慢,它会减慢Redis吗？
以下是我的答案:
想要更多地了解这种魔力.
Redis真棒,但没有魔法.它只是一个非常务实的概念的智能和有效的实现.而且因为它是一个人性化的项目,通过查看源代码实际上很容易理解为什么.
这只是网络延迟还是Redis必须保持一些开销,直到整个数据被刷新.
当然,Redis必须维护通信缓冲区,以便它可以处理较慢的网络链接.也就是说,这应该对感知的延迟产生很小的影响.在您的情况下,50毫秒可能主要是由于网络延迟,您可以通过运行ping命令或任何其他类似工具来检查.
连接数可以影响Redis吞吐量吗？
当然,它可以像任何服务器软件一样.现在,您需要区分每个连接的吞吐量和服务器的全局吞吐量.
每个连接的吞吐量受连接数的严重影响.考虑服务器只能提供一定的带宽,并且这些带宽在连接之间共享.连接越多,每个连接的带宽就越少.
另一方面,服务器的全局吞吐量仅受连接数的轻微影响.Redis可以接受成千上万的连接,没有任何问题.但仍然存在开销.根据经验,考虑到在30000个连接处,Redis仅支持100个连接可支持的吞吐量的一半.请参阅Redis基准页面上提供的漂亮图表.
最后一个请求是否需要500muSec*1000 = 500ms？
是的,但你的数字可能是错的.
是的,所有活动都是序列化的(单线程设计),因此必须添加每个命令的处理时间.当同时接收到许多命令时,最后一个命令将在所有其他命令之后被提供.如果每个命令需要5我们应该在处理,和1000在同一时间收到,最后的答复将在5毫秒发送.
现在,实际上,真正并发查询的数量并不高.Redis很少在同一事件循环迭代中同时接收1000个查询.
此外,您会混淆响应时间(在客户端测量)和处理时间(将在Redis端测量).的响应时间可以是500我们,但处理时间是多少我们更接近5,区别在于所花费的网络上,并在OS进程调度的时间.请记住,只需要累计处理时间,其他所有内容都通过连接进行并行化(例如网络延迟).
要计算实例的平均处理时间,只需使用redis-benchmark来使实例饱和.使用流水线时,看到处理速度高达400 Kop/s或更高的情况并不罕见,平均处理时间为2.5 us.
响应大小可以在这里产生影响吗？
当然,它可以像任何服务器软件一样.超过一定的大小,延迟总是受数据量的影响,因为网络的带宽和速度都是有限的.对于以太网网络,此阈值与MTU的大小密切相关.
Redis上的TCP连接必须等到最后一个数据包交付,如果网络连接速度慢,它会减慢Redis吗？
绝对不.Redis系统地缓冲回复(无论其大小),并通过事件循环以非阻塞方式管理所有套接字.如果一个连接速度很慢(或者一个客户端很慢),Redis将尽可能多地填充相应的套接字缓冲区,在事件循环中注册套接字,然后移动到另一个连接.当套接字缓冲区中再次出现空间时,事件循环将继续在慢速连接上发送流量.什么都没有阻止.
| 归档时间： |
|
| 查看次数： |
1115 次 |
| 最近记录： |