问题
我有兴趣了解每个 memcached 实例的以下指标：
- 每秒连接/GET/SET 的安全范围
- 每秒连接数/GET 数/SET 数的上限
我感觉真正的瓶颈是连接，但希望得到在其网站上安装了 memcached 的人的意见。
背景
我运营着一个网站，该网站一个月的页面浏览量达到数亿次。该网站分布在多个 Web 服务器上。该网站最初使用基于文件的缓存架构进行编码，该架构不由 Web 服务器池共享；每个 Web 服务器都维护每个页面的缓存副本。
出于显而易见的原因，我们正在迁移到 memcached。我们转换了流量较低但更动态的页面（又称“缓存命中率较低的页面”），没有任何问题。现在，我们正在转向流量较大但更静态的页面（又称“应该看到更高缓存命中率的页面”）。我们首先转换了流量最低的页面，并且已经看到平均每秒 3.5k GET 跃升至平均每秒 11k GET。我们看到平均在任何给定时间都有 400-600 个连接处于活动状态。我们的连接限制在我们的配置文件中设置为 4k。
考虑到我们仍有流量最高的页面需要实现，这似乎是研究 memcached 的可接受范围和上限的好时机。这样，我们可以在将网站流量最高的部分转移到 memcached 之前确定是否需要扩展到其他 memcached 实例。我意识到我们的使用情况现在没有必要担心，但我想知道什么时候会发生，而且我希望事先知道。
答案1
根据我的经验，并发连接数比 GET/SET 数更重要。我现在正在查看历史 Cacti 图表，该图表显示 memcached 实例每秒最多可获得约 4M 次访问（2.8M 次 GET 和 1.2M 次 SET）。我怀疑这些数字是否真实。无论如何，它们是仅使用一个活动连接实现的。问题是，当我使用网站负载测试工具对此设置进行压力测试时，memcached 开始以每秒仅约 2-3K 次访问的速度占用 CPU。我不得不建立一个 memcached 场来分配负载。如您所见，并发连接数和 memcached 可以处理的每秒访问数之间存在非线性关系。Memcached 似乎在一定数量的并发连接上开始迅速降级，您确实需要对您的设置进行压力测试以确定这个关键数字。
答案2
也许更好的方法是查看与 memcached 交互时的性能限制。一些脚本可以确定您一天的平均响应时间，这是一个不错的起点。
关于你的主要问题：
我认为，一般来说，并发活动 (gets/sets) 的数量会因硬件配置而异，因此对此的任何回应都是主观的。我认为找到一种更好的方法来衡量相对于您自己的环境的成功才能直奔主题。如前所述，压力测试自然在这个过程中非常重要。
干杯
答案3
没有神奇的公式可以预测容量——您需要通过实验和数值分析来做到这一点。
我们已经看到平均每秒 3.5k GET 跃升至平均每秒 11k GET
如果您说这是实施变更的结果，那是否意味着您之前由于性能问题损失了三分之二的流量？
虽然这些指标表明你可以用更少的硬件来处理更多的流量，但你是否使用适当的网络模拟来测量对响应时间的影响？
您需要规划一个架构，以便控制缓存的内容和位置 - 您希望能够轻松地将负载分配到多个 memcached 实例，并具有一定的故障转移能力。这会变得非常复杂，非常快 - 这是我倾向于将 memcached 留到最后手段的原因之一 - 并且永远不会将其用作前端缓存。另一个原因是，在我测试过的地方，与其他共享数据的方法（前端的反向代理、中间的良好调整以及后端的分布式共享存储）相比，收益微不足道。但我非常清楚，架构需要反映用于构建系统的组件 - 我的经验主要是中型 LAMP 类型的系统 - 但具有拆分应用程序服务器层的模型非常不同。