java tcp链接慢_连接到redis时，Unix套接字比tcp慢

Unix域套接字通常比环回接口上的TCP套接字快 . 通常，Unix域套接字的延迟平均为2微秒，而TCP套接字则为6微秒 .

如果我使用默认值(没有管道)运行redis-benchmark，我会看到每秒160k的请求，主要是因为单线程redis服务器受TCP套接字限制，160k请求以6微秒的平均响应时间运行 .

使用Unix域套接字时，Redos每秒可实现320k SET / GET请求 .

但是有一个限制，实际上我们在Torusware上已经达到了我们的产品Speedus，这是一个高性能的TCP套接字实现，平均延迟为200纳秒(请发送电子邮件至info@torusware.com申请Extreme Performance版本) . 延迟几乎为零，我们看到redis-benchmark每秒可实现约500k个请求 . 所以我们可以说redis-server延迟平均每个请求大约2微秒 .

如果您想尽快回答并且您的负载低于redis-server峰值性能，那么避免流水线操作可能是最佳选择 . 但是，如果您希望能够处理更高的吞吐量，那么您可以处理请求的管道 . 响应可能需要更长时间，但您可以在某些硬件上处理更多请求 .

因此，在前一个场景中，使用32个请求的管道(在通过套接字发送实际请求之前缓冲32个请求)，您可以通过环回接口每秒处理多达100万个请求 . 在这种情况下，UDS的优势并不高，特别是因为处理此类流水线操作是性能瓶颈 . 实际上，管道为32的1M请求每秒大约有31k“实际”请求，我们已经看到redis-server每秒能够处理160k个请求 .

Unix Domain Sockets分别处理大约每秒1.1M和1.7M的SET / GET请求 . TCP环回每秒处理1M和1.5个SET / GET请求 .

通过流水线操作，瓶颈从传输协议转移到管道处理 .

但是，流水线操作会大大增加响应时间 . 因此，没有流水线操作，100％的操作通常在不到1毫秒的时间内运行 . 当流水线操作32请求时，高性能服务器中的最大响应时间为4毫秒，而如果redis-server在不同的计算机或虚拟机中运行，则最长响应时间为几十毫秒 .

因此，您必须权衡响应时间和最大吞吐量 .