用muduo实现memcached协议的例子

用muduo实现memcached协议的例子

最近花了两天时间用 muduo 部分实现了 memcached 服务器协议,代码位于 examples/memcached/server,能通过 memcached 的大部分测试用例(incr/decr 还没有实现)。

这不是 memcached 的替代品(它没有实现LRU和超时功能,也没有实现二进制协议,更没有自己管理内存),而是一个网络编程的示例(代码只有 1000 行,比 memcached 小很多),展示 muduo 风格的事件驱动编程,以及将来性能优化的试验品(换句话说,现在这个版本完全没有在性能上做出任何努力)。读过 memcached 代码的人可以对比这两种编程风格的区别,memcached 的 read/write 操作穿插于正常逻辑处理,而 muduo 的网络数据读写是由库完成,应用程序只关心消息收发,目前二者的基本 get/set 操作的性能相当。

现在 muduo 的 inspector 内置了 gperftools 的远程 profiling 功能,memcached-debug 展示了其用法。

为什么不必优化 set 操作(含 set/add/update/append/prepend/cas 等)的性能?

1. 比例。既然是 memcache,那么 get:set 的比例很高,10:1 甚至更高,因此优化的重心应该是 get 而非 set。

假设 memcached 能处理 100k QPS,再假设这些操作都是 set(其实应该不到 10% 是 set),再假设所有的 set 都是串行执行的(没有并发),那么每次 set 的 CPU 时间不应该超过 10 us(含服务器本地的网络代码运行时间,但不含网络延迟)。而实际上一次 set 的 CPU 时间最多是 2~3 us (用 memcached-footprint 程序测得),根本不值得优化。

2. 网络带宽。假设一次 set 操作的 key + value 的长度是 1k bytes,TCP 的有效载荷带宽按110MB/s估算,那么1kB数据在千兆网上的惯性延迟是 9us(传输延迟是几十上百微秒,与此无关),也就是说服务器的网卡收到这 1kB 数据需要花 9us 时间(从第一个字节到达到服务器到收完最后一个字节),那么在 set 耗时 2~3 us 的情况下再去优化它是做无用功。

3. 产生“需要更新的数据”的成本远大于 memcached set 的开销。memcached 需要更新,往往是将已写入数据库的新数据放到 memcached 中,那么写数据库的开销远远大于 memcached set 的开销,优化 set 对提升系统整体性能没意义。

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页