memcached优化始末
我们线上服务一直使用memcached作为cache服务器，客户端使用的是libmemcached，示意图如下。 问题现象 我们发现item平均大小仅为10KB左右，结果memcached set的平均延时就有7ms之多。我们之前已经在libmemcached里面设置了TCP_NODELAY。 libmemcached在set/g
我们线上服务一直使用memcached作为cache服务器，客户端使用的是libmemcached，示意图如下。
问题现象
我们发现item平均大小仅为10KB左右，结果memcached set的平均延时就有7ms之多。我们之前已经在libmemcached里面设置了TCP_NODELAY。
libmemcached在set/get之后会接收服务器返回的数据，如果一次没有收到，就会循环调用poll等待服务器返回数据。
while (1)
{
int enable = 1;
setsockopt( ptr->fd, IPPROTO_TCP, TCP_QUICKACK, (void *)&enable, sizeof(enable));
data_read= recv(ptr->fd, ptr->read_buffer, MEMCACHED_MAX_BUFFER, 0);
setsockopt( ptr->fd, IPPROTO_TCP, TCP_QUICKACK, (void *)&enable, sizeof(enable));
if (data_read > 0)
{
break;
}
else if (data_read == SOCKET_ERROR)
{
ptr->cached_errno= get_socket_errno();
memcached_return_t rc= MEMCACHED_ERRNO;
switch (get_socket_errno())
{
case EWOULDBLOCK:
#ifdef USE_EAGAIN
case EAGAIN:
#endif
case EINTR:
#ifdef TARGET_OS_LINUX
case ERESTART:
#endif
if ((rc= io_wait(ptr, MEM_READ)) == MEMCACHED_SUCCESS)
continue;
/* fall through */
default:
{
memcached_quit_server(ptr, true);
*nread= -1;
return rc;
}
}
}
剑豪使用systemstap发现经常有超过40ms的poll，这是一个很重要的线索，我使用strace也可以看到很多超过40ms的poll。
经过一系列测试发现，流量越小，延时反而越高。但是为什么延时又随着QPS的波动而波动呢？我想应该是这样的，memcached_st对象池使用stack保存，使用的顺序是后进先出。当流量小的时候，会一直使用栈最上面的一两个memcached_st对象，所以对某个memcached服务器的压力可能不必流量高峰低。
问题缘由
经过来回折腾，我发现客户端和服务器端都存在DELAYACK的情况，客户端会对服务器的响应做DELAYACK，不会影响性能。真正奇怪的是客户端设置了NODELAY，但是有时候它会等待服务器发送ACK，才接着继续发数据。并且由于服务器都开启了TSO、GRO等特性，使用tcpdump看不到网卡做的事情，tcp经常push一个远大于MSS的包出去，似乎也根本不考虑服务端的接收窗口大小。
下图中487、488、489三行在做一个get，没有命中cache之后，从490行开始做set，结果服务器的ack delay了，导致客户端发送第二个包的时候等了40ms。
我甚至怀疑TCP_NODELAY没有设置上，但是在代码中使用getsockopt将TCP_NODELAY的值打印出来，发现确实是1。
NOREPLY
无意中看到memcached支持NOREPLY选项（这个选项libmemcached同样也支持，要不然一个巴掌拍不响），真是如获重宝啊，实际线上的效果如下，现在set的latency已经可以忽略不计了。我想世界上所有非关键的服务都应该支持NOREPLY这个选项。
一点小结
1、TCP_NODELAY之所以没起作用，应该和gro有关系。我做了一个测试，发现关闭gro之后，poll超过40ms的情况减少了很多。如果不能理解其中的奥义，就很难解释为什么流量大，延时反而会降下来这个现象。
2、libmemcached这种每个memcached_st对象对每个memcached服务器都有自己连接的方式，特别容易导致每个连接压力都很小，导致延时变得特别高。这种压力能小到什么程度呢？假设有30台memcached服务器，客户端set的QPS是1K，多线程导致一共有30个memcached_st对象，那么一个socket的set QPS就是1K/(30*30)=1。
淘宝自己的tbnet/anet网络通讯库是复用socket的，每个包通过channel id来标识自己，可以使socket保持高压力，不容易出现上面这个问题。
原文地址：memcached优化始末, 感谢原作者分享。