加载测试CMS Web应用程序的实际测量是什么？

Question

我们公司的CMS网络应用程序面临一些困难。这个应用程序是由承包商部分构建的，当我们认为应用程序应该能够处理它时，我们遇到了一些稳定性问题（崩溃，必须将它们放在负载平衡器或缓存机制之前）。我们整理了一个最小的标准测量，但我们不知道这些指标是否切合实际。

我们希望能够在这个论坛上获得有关CMS系统应该独立于所构建技术的现实期望的反馈意见。因此，如果要在.NET而不是Java（当前）中构建相同的应用程序，您将期望执行相同的操作。

我们提出的指标是：

• 并发请求数/队列长度：100最大值
• 提出请求的时间：最少2秒
• 每小时的请求数：150,000
• 每小时的最小网页浏览量：5,000

最低HD要求：   - 2 GB Ram   - 2个双核2.0 Ghz

一般功能：

• 动态交叉引用（人们对 新闻，人与新闻事件， 技术案例等）
• 高级搜索功能
• 高度可配置，无需编程

Answer 1

制作具体表演并不合理。没有任何关于硬件，技术，负载，使用等信息的可扩展性期望“CMS”非常广泛：

• 您的服务器场是什么样的？
• 您的SLA有哪些条款？
• 您的典型用户是什么样的？例如。许多简短的用户或更少的用户有很长的会话和许多请求？

要回答的其他重要问题：

• 你想测量“第一个字节的时间”（我讨厌这个，但这很常见），或者在你的“服务时间”中包含网络延迟？
• 有多少编辑正在反对该系统？
• 您的编辑是否针对相同的数据支持工作，或者他们是否在隔离环境中准备内容并推送批量内容更新？
• 您可以支持哪种缓存机制？内容可以陈旧数分钟/小时吗？

在我们的几个负载平衡的64位服务器的农场中，每个服务器有大约32GB RAM（IIRC）和4个CPU，我们的平均每小时请求不到10万，峰值负载为几百个请求/秒（不常见）。总最终用户加载时间（包括图像和资产）必须低于5秒。我们的CMS内容数据库总数不到750,000页。我们有大量的交叉加载内容，查询，复杂的编辑器可配置小部件等。

Answer 2

您应该开始做的是跟踪人们如何使用它。如果您要保留网络日志，则会随着时间的推移和活动的会话数量等提出请求。

然后，您应该使用这些指标来确定您的负载/压力测试应该是什么样的。一次有多少用户在峰值事务级别对其进行负载测试 - 将读取与写入归零。

Answer 3

很难回答你的问题。 您提到了服务器的硬件，但我不清楚这些硬件是用于数据库服务器还是应用程序服务器（或者如果您使用相同的硬件）。 您还没有向我们提供有关您的数据库的信息......

在不了解您的应用程序架构的情况下提供帮助更加困难。一些架构决策，如数据库缓存，高级前端优化技术，数据库调优，全文索引，异步处理（通过消息队列）可以在应用程序性能和可伸缩性方面产生巨大的差异。

无论如何，我建议你使用一些负载测试工具，如JMeter，Silk Peformer，Load Runner等。

Answer 4

我们公司使用带有3组不同脚本的load runner。 1个脚本是模仿网站，主页，登录，导航到主题区等的基本用例.... 第二个脚本是基于100个可能的搜索词进行随机站点搜索。第三个测试用于回复向我们的订阅者发送大量电子邮件的用例。

每个脚本我们重复动作20次。

我们以100个并发用户运行第一个脚本，从1个用户开始，每30秒增加5个，然后我们运行并提取统计信息。

我们以20个并发用户运行第二个脚本，从1个用户开始每30秒增加2个

我们以500个并发用户运行第3个脚本，从1开始，每5秒增加10个。

重要的是我们运行相同的负载测试，并在每次更改基础架构时跟踪/分析结果。

加载跑步者跟踪响应时间，失败率和一些其他统计数据......对于远程代理，它也可以跟踪数据库和服务器的生命周期。

Answer 5

表演问题很少直截了当。坦率地说，您应该真正了解熟练的集成商的服务，了解您正在使用的CMS和性能优化。找出网络/ CMS本身/其实现之间的瓶颈总是很棘手。

你的规格看起来相当“标准”，这里没有任何期望，所以我怀疑更多的实施或网络问题比直接CMS（我不能说它不是CMS，我想说，那将是令人惊讶......令人失望。如果它是一个众所周知的密切供应商，一个着名的开源供应商，那么CMS不是原因的机会正在快速上升。）