毫无疑问，memcache是大型网站必备的利器，但是memcache本身也会有性能极限。网上关于memcache的性能讨论并不多，这里以实际的例子来说明些经验值。如何测量memcache的性能和时延还是一个未解决的问题。

比如我们的一台服务器上观测到memcache的请求次数为14000次/秒，此时服务器上会显示出比较奇怪的现象，mysql和httpd线程数量都迅速增加，并且mysql线程处于长时间的sleep状态，平时1秒左右可以执行完的PHP脚本需要30-40秒才能执行完毕，可以推断此时memcache的性能已经受到十分严重的影响。

准备使用一些工具来监测memcache的性能，包括每秒请求次数。

memcache的每秒请求次数可以通过telnet memcache，然后stats命令得到:

[~]$ telnet 192.168.1.1 11211
Trying 192.168.1.1...
Connected to java.labs.chinamobile.com (192.168.1.1).
Escape character is '^]'.
stats
STAT pid 4384
STAT uptime 31352450
STAT time 1291734795
STAT version 1.2.5
STAT pointer_size 64
STAT rusage_user 1009910.129323
STAT rusage_system 5275835.119150
STAT curr_items 260933
STAT total_items 425104890
STAT bytes 3723186867
STAT curr_connections 33
STAT total_connections 763383
STAT connection_structures 676
STAT cmd_get 360491827286
STAT cmd_set 427219337
STAT get_hits 360145594675
STAT get_misses 346232611
STAT evictions 87801741
STAT bytes_read 14328038962902
STAT bytes_written 413742549101562
STAT limit_maxbytes 4294967296
STAT threads 1
END
有些软件直接使用cmd_get的值去除uptime，得到一个每秒请求数量，这个计算方法并不能准确反映当前memcache的负载。比较准确的算法是使用两次stats结果的差值来计算。

网上有facebook的工程师讨论过请求数量和反应时间（latency）之间的关系[http://tech.byreach.com/node/2081]，一般来说，请求数量越多，反应时间就越长。facebook的服务器经过各种令人惊奇的优化，包括对udp协议的使用，对udp的协议的轮询方式的改变等等，可以获得20万次/秒的性能。如果提高到30万次每秒，那么反应时间将超过实用的范围。

memcache负载过高可以通过CPU的load过高的现象来观察到。