我正在尝试估计 WordPress AWS 设置可以承受的并发用户数量（需要高可用性并支持巨大负载）。他们要求我给出一个我们可以保证的宽松范围（他们问了一位刚接触 DevOps 的人……）。
该架构如下所示：
r5.2xlarge数据库的两个 RDS实例 (主实例 + 读取副本)。t2.2xlarge管理 1 到 25 个EC2 实例的自动扩展组。- CloudFront 作为内容的 CDN。
有关申请的一些条件：
- 约有 1300 种出版物。
- 每页大小在 200 Kb 到 3 Mb 之间（非常罕见），大部分在 500 Kb 左右。
显然，目标是获得“合理”的响应时间，尽管我还没有被告知具体的范围。
经过并发用户我是说并发请愿或点击量。我很想实际测试一下，但不幸的是我需要很多付费资源。
我真的不知道哪种推理在这里适用。到目前为止，我发现最有帮助和最相关的是这- 但是，情况完全不同，我们无法真正获取数字并对其进行线性缩放。该帖子的作者测量了 18 个t2.medium实例以 60% 的运行率运行 WP，可以以 90 RPS 运行 WP，并保持大约 350ms 的响应时间。我无法理解将这个结论扩展到我的架构。
理想情况下，除了回答我的问题之外，我还想找到一种方法来有效回答这些问题。
答案1
通常我们不会被问及给定架构可以承受多少用户，而是会被问及需要什么样的架构来承受给定数量的用户。这不是更重要的问题吗？
无论如何，有几点需要注意：
- 如果你将架构设计为在所有层面上真正可扩展- 内容交付（Cloud Front）、Web 服务器（无状态、一次性）、文件存储（EFS、S3）、数据库（例如 Aurora、只读副本） - 那么你不必太关心特定配置可以支持多少用户。如果需求较低或较高，架构将简单地扩展以满足需求。
您的架构似乎在可扩展性方面走在正确的道路上，所以我想最好的方法是进行概念验证并进行 专业负载测试。有些公司可以在地理上分散的地点进行此操作。这将向您展示您的设计如何执行，然后您将能够插入各种并发用户数所需的各种配置。
关于T2 实例类型- 他们使用所谓的CPU 积分这使得它们在短时间内运行得很快，然后速度变慢。当它们空闲时，它们会再次积累这些信用，并在一段时间内再次运行得更快。这对于峰值负载来说很棒，但对于持续负载，你最好使用例如M5 实例类型（例如 m5.large） - 这些提供一致的性能。
最好有较小实例的数量更多（例如20x m5.大）而不是少量的大实例（例如5x m5.2x大) - 扩展和扩展更顺畅，磁盘性能更好，单个节点的故障不会产生太大影响，等等。
考虑使用Spot 实例和现货车队以进一步节省您的实例成本。
你提到你提供一些出版物- 如果这些是静态 PDF 文档，你最好将它们存储在 S3 中，并且CloudFront 直接从 S3 读取它们完全无需通过 WordPress。如果它们不是公开的，需要订阅，请查看CloudFront / S3 签名 URL。这将大大减少您的 WordPress 服务器的负载。
希望有帮助:)