- 现在我使用的是XMemcached。
统计信息
可以通过nc命令向Memcached服务端发送消息来获取统计信息，例如：
|
1
|
echo "stats settings" | nc localhost 20200 | sort
|
但是，我更需要客户端的统计信息，尤其是缓存命中率，set操作成功率等等。所以在客户端添加了一个简单的统计模块。每次处理用户请求的过程中，通 常有两次向Cache服务端的提交get请求，很多情况下还有两次set请求，合计消耗17ms，在把set请求改成NOREPLY模式以后，这个数减少 到10ms以内。因此，对于实时性要求比较高的情形，请打开这个模式，或者干脆使用异步的set。
服务端参数
- 可以使用-U来使用UDP传输，但是收效不大。
- -k参数可以阻止换页操作发生，在内存足够的情况下对提高性能有益。
- -C参数可以禁用CAS。
- -t指定使用的线程数，如果你是多CPU、多核CPU，可以把这个值配成和总CPU核数一致。
- -f参数，增长因子，存储大对象把它配大一点可以提高效率，配小一点可以减少浪费。
客户端参数
- 在使用Memcached Java Client的时候：
- 由于它会使用direct memory，一定不能加上DisableExplicitGC这个参数，否则就等着OOM吧；
- 配置大一些的heap size可以提高L1 cache的命中率；
- 把alive check置为false。
- 对于实时性和响应性要求比较高的项目，需要做GC调优，主要是GC时延，比如配置MaxGCPauseMillis参数到一个可以接受的值，但是不是越小越好，减低时延的同时会降低吞吐量。
- 有同事提了个建议，在客户端存放一个cache key的集合，可以在去cache server查询之前，先在本地查看一下是否有缓存记录（比如用Bloom filter来 实现），如果有，再去cache server查询。这个集合可以和实际的cache key有出入，也许一个小时同步一次就可以。但是实际上实现起来比较困难，本身key set的总量非常大，而且Memcached最初提供获取key iterator的接口返回的是一个限定大小key set的iterator，缺乏实际意义（这个接口在后来Memcached的版本中已经被废弃）。至于stats方法，它会把所有cache对象 dump出来，只能小规模调试的时候使用。
- 关于Nagle算法：Nagle的好处是可以批量处理请求，提高TCP包有效部分的大小，从而提高网络利用率，但是如果对每个请求处理时延要求很高的话请关闭。
- 一定要指定socket timeout或者get/set timeout。
最后，有人做了一个几个Memcached客户端的综合的性能试验：链接。
文章系本人原创，转载请保持完整性并注明出自《四火的唠叨》