服务端 高性能 （三） network

前两篇主要从cpu和memory两个方面讨论了服务端高性能优化，现在谈谈rpc这块，

服务端现在主要有两种调用：

远程redis调用
远程thrift调用

远程redis调用现在是部署了读写分离来提高读写效率；另外，说一说之前遇到的一个问题，
我们的业务每个线程都要从redis读取几K的数据，发现这块耗时很不稳定，有时候这个时间
会出现41ms,83ms这么长的时间，用tcpdump观察，发现在ack的时候有40ms的延迟，从
而导致这种情况的发生；这种情况是tcpdelayack引发的，主要两种原因：

nagle算法
窗口拥塞
redis server端和client端都已经设置了tcpnodelay=true，禁用了nagle算法，那就是窗口

拥塞导致这种情况了，所以这块要进行限流，现在解决方案：
对大数据块进行分批次获取，每次获取部分数据（多测试尽量避免tcpdelayack）；

远程thrift调用注意两点吧：

设置超时
加好缓存
超时现在是1s,太长会引发性能问题，如果远程thrift接口性能更好的话可以更适当的缩小
超时时间；

现在远程thrift接口是一个cpu密集型服务，所以这块其实也比较耗时的，所以上层调用端
可以给这里加缓存，我这里主要加了两层缓存：进程内缓存和远程redis缓存，当然如果追求
更高性能，为了防止重启服务器进程内热点缓存丢失的话可以在重启之前把缓存load到文件
然后重启的时候再进行warmup。

另外，redis client对象和调用thrift socket这块要调用连接池，减少建立连接的开销，同时
也能控制对象的成本。