我正在努力扩展memcached。 从他们的网站：
Memcached操作几乎都是O（1）。 连接到它并发出get或stat命令不应该滞后。 如果连接滞后，您可能会达到最大连接限制。 有关要监视的统计信息的详细信息，请参阅ServerMaint。
如果发布命令滞后，则可能有许多调整问题。 最常见的是硬件问题，没有足够的RAM（交换），networking问题（带宽，丢包，半双工连接）。 在罕见的情况下，操作系统错误或memcached错误可以贡献。
那么..对我来说，这绝对不是一个O（1）的操作。 在我们站点的低到正常的负载下，memcached get和set操作的响应时间大约是0.001秒。 不错。 但是如果我们将负载增加了三倍，那么我们就会得到100倍（或极less数情况下为1000倍）的exception值。 我甚至有一个例子，memcached用了2.2442秒来存储一个值。
显然这是杀害我们的网站。
这是Memcached-> getStats在缓慢期间的输出：
[pid] => 18079 [uptime] => 8903 [threads] => 4 [time] => 1332795759 [pointer_size] => 32 [rusage_user_seconds] => 26 [rusage_user_microseconds] => 503872 [rusage_system_seconds] => 125 [rusage_system_microseconds] => 477008 [curr_items] => 42099 [total_items] => 422500 [limit_maxbytes] => 943718400 [curr_connections] => 84 [total_connections] => 4946 [connection_structures] => 178 [bytes] => 7259957 [cmd_get] => 1679091 [cmd_set] => 351809 [get_hits] => 1662048 [get_misses] => 17043 [evictions] => 0 [bytes_read] => 109388476 [bytes_written] => 3187646458 [version] => 1.4.13 所以我迄今排除的事情是：
curr_connections的84远低于默认的最大1024） bytes统计。 我将如何诊断其他硬件问题？ 在CPU或内存使用方面，prstat并没有真正显示出一大堆。 不知道如何找出networking问题，但因为这是一个专门的服务器在同一个私人networking的networking盒子，我不认为这是一个连接问题（ ping是不到一个毫秒之间的盒子）。
还有什么我在这里失踪？ 这让我疯狂。
编辑：也忘了提到，我已经尝试了持久和非持久的连接，影响最小。
如果使用交换内存，Memcached性能可能会显着降低。 如果您注意到服务器正在使用交换内存，则可以尝试使用-k选项启动memcached。
来自： http : //code.google.com/p/memcached/wiki/NewHardware#Avoid_Swapping
避免交换
将物理内存分配给memcached服务器。 不要过度分配内存，并期望交换来保存你。 性能会非常非常差。 要格外小心，以监视您的服务器是否正在使用交换，并在必要时进行调整。
我把操作系统从SmartOS改为Ubuntu，这个问题似乎已经解决了。 不知道为什么，但似乎是memcached和操作系统之间的问题。
问题最终导致呼叫机器使用其所有导致其TCP连接的CPU严重滞后。 横向扩展Web层解决了这个问题。 事实certificate这根本不是一个memcached的问题 – 这就是其他问题的症状出现的地方。