我们正在使用 Newrelic 来衡量我们的 Python/Django 应用程序性能。Newrelic 报告称，在我们的系统中，“Memcached”平均需要 来12ms响应命令。
深入研究排名前十的网页浏览量（按请求数计算），我发现有些网页浏览量Memcache get最多需要30ms；我找不到一个使用时间Memcache get少于的网页返回结果10ms。
有关系统架构的更多详细信息：
- 目前我们有四台应用服务器，每台都有一个 memcached 成员。所有四个 memcached 成员都参与 memcache 集群。
- 我们在云托管提供商上运行，所有流量都在“内部”网络上运行（通过“内部”IP）
- 当我从一个应用程序服务器 ping 另一个应用程序服务器时，响应如下
~0.5ms
不是10ms一个慢的Memcached 的响应时间？
据我了解如果你认为“Memcache 太慢了”然后“你这样做是错的”。那么我做错了吗？
以下是该命令的输出memcache-top：
memcache-top v0.7 (default port: 11211, color: on, refresh: 3 seconds)
INSTANCE USAGE HIT % CONN TIME EVICT/s GETS/s SETS/s READ/s WRITE/s
cache1:11211 37.1% 62.7% 10 5.3ms 0.0 73 9 3958 84.6K
cache2:11211 42.4% 60.8% 11 4.4ms 0.0 46 12 3848 62.2K
cache3:11211 37.5% 66.5% 12 4.2ms 0.0 75 17 6056 170.4K
AVERAGE: 39.0% 63.3% 11 4.6ms 0.0 64 13 4620 105.7K
TOTAL: 0.1GB/ 0.4GB 33 13.9ms 0.0 193 38 13.5K 317.2K
(ctrl-c to quit.)
** 以下是该命令在一台机器上的输出top：** （在所有集群机器上大致相同。您可以看到 CPU 利用率非常低，因为这些机器只运行 memcache。）
top - 21:48:56 up 1 day, 4:56, 1 user, load average: 0.01, 0.06, 0.05
Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Mem: 501392k total, 424940k used, 76452k free, 66416k buffers
Swap: 499996k total, 13064k used, 486932k free, 181168k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6519 nobody 20 0 384m 74m 880 S 1.0 15.3 18:22.97 memcached
3 root 20 0 0 0 0 S 0.3 0.0 0:38.03 ksoftirqd/0
1 root 20 0 24332 1552 776 S 0.0 0.3 0:00.56 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0
5 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kworker/u:0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
7 root RT 0 0 0 0 S 0.0 0.0 0:00.62 watchdog/0
8 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cpuset
9 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
...output truncated...
答案1
我发现写入速度非常快，单次读取非常慢，但缓冲读取非常快。您需要使用 get_many 进行缓冲读取，并传入要检索的键的数组。这是我的测试：
WRITE 写入 100000 次（一次写入，但可能在后台缓冲）耗时 0.42605304718 秒，每秒 234712 次
读取 100000 次，存储桶大小为 10000 次，读取（多次）耗时 0.651949167252 秒，每秒 153386 次
每次读取 100000 个，耗时 86.2907109261 秒，每秒 1158 个
就我而言，我使用带有 pymemcache 的 python。
答案2
到目前为止，我的研究表明这10ms很“慢”。我的意思是，memcache 文档本身将子1ms时间称为“预期时间”。所以我们看到的响应时间要慢一个数量级。
对性能的期望：https://code.google.com/p/memcached/wiki/NewPerformance
导致 memcached 响应缓慢的“可能原因”似乎是（按可能性大致排序）：
- 应用程序设计不佳（或有错误）
- 网络拥塞
- 交换
- 共同租户应用程序导致 CPU 负载过高
- 达到某种连接最大值
- 状态防火墙
- 错误的 TCP 配置
我几乎已经解决了所有这些问题，如下所示：
- 根据
memcached-top（https://code.google.com/p/memcache-top/）我们从应用程序获得的连接时间与运行时大致相同brutis（https://code.google.com/p/brutis/) 来自相同的应用服务器。 - 尽管我们的系统有明显的峰值负载时间，但响应时间全天保持一致；如果这是拥塞问题，响应时间永远不会像人们所期望的那样“突然增加”。（此外，我们的托管服务提供商声称为这些实例提供的 Mbps 远远高于
atop我们使用的报告） - 观察到系统上有足够的可用内存（并且没有 iowait）
- 整个缓存的 CPU 使用率低
- 每台服务器仅支持 10-20 个同时连接
- 我们正在使用状态防火墙（通过 iptables），但是当我们删除所有状态条目时，性能并没有变化。
盲目地设置这些配置选项并希望它们能够改善情况：
/sbin/sysctl -w net.ipv4.tcp_tw_recycle=1 /sbin/sysctl -w net.ipv4.tcp_tw_reuse=1 /sbin/sysctl -w net.ipv4.tcp_fin_timeout=10
结果没有变化。
我们基本上不知道该如何诊断这个问题。我们正接近“安装 Redis”的阶段，希望它能更好地工作。
答案3
首先想到的是：您是否使用 FQDN/DNS 启动与 memcache 服务器的连接，还是使用 IP 地址或本地套接字？
如果您使用主机名，则可能会在名称解析中浪费一些时间。
尝试将 FQDN 放入客户端和服务器的 /etc/hosts 中并重新启动，以便不缓存任何内容，或者将引用更改为基于 IP 地址，看看是否没有看到改进。
答案4
我刚刚完成了 memcached 刷新，所以我想发布一个我认为有效的示例输出。New Relic 报告在 memcached 上花费了 10.4 毫秒，所以我认为它计算了多个调用。您是在裸机上运行还是在虚拟机上运行，如果您关心速度，那么虚拟机不是最佳选择（http://redis.io/topics/benchmarks）
memcache-top v0.6 (default port: 11211, color: on, refresh: 3 seconds)
INSTANCE USAGE HIT % CONN TIME EVICT/s READ/s WRITE/s
app01:11211 0.5% 49.8% 2994 0.7ms 0.0 75.2K 378.5K
app02:11211 0.5% 51.7% 2992 0.7ms 0.0 76.5K 143.9K
app03:11211 1.0% 69.6% 1469 0.7ms 0.0 42.0K 161.3K
app04:11211 2.0% 52.6% 801 0.5ms 0.0 66.0K 415.9K
app05:11211 2.2% 52.5% 801 0.4ms 0.0 71.9K 171.2K
app06:11211 2.0% 66.4% 800 0.5ms 0.0 135.9K 180.4K
app07:11211 1.9% 52.0% 800 0.6ms 0.0 65.5K 482.4K
app08:11211 1.1% 87.1% 1469 0.7ms 0.0 59.3K 365.3K
db01:11211 1.0% 82.4% 1469 0.5ms 0.0 64.6K 155.4K
elastic01:11211 1.7% 69.9% 737 0.5ms 0.0 44.2K 128.8K
elastic02:11211 1.7% 65.0% 737 0.5ms 0.0 48.2K 155.8K
elastic03:11211 1.8% 68.3% 737 0.6ms 0.0 24.5K 115.7K
elastic04:11211 1.8% 69.5% 737 0.7ms 0.0 95.3K 158.0K
AVERAGE: 1.5% 64.4% 1272 0.6ms 0.0 66.9K 231.7K
TOTAL: 12.1GB/ 1.0TB 16.2K 7.6ms 0.0 869.1K 2.9M
(ctrl-c to quit.)