负载测试web-app

Question

在对基本Web应用程序进行负载测试时，除了预期的响应时间之外，您还会进行哪些健全性检查？ 请求峰值内存使用是否公平？ 您还做了哪些其他检查？

Answer 1

在服务器上

• 应用程序可以承受的每秒请求数
• 每秒针对数据库的请求数（如果有的话，与上面的数字相关，但将它们作为单独的数字有用）
• 传输带宽（如果可能，按媒体类型分隔）
• CPU利用率
• 内存利用率

在客户端

• 响应时间
• 平均页面的重量
• 任何时候CPU使用率都很高
• 运行类似YSlow的内容，看看您可以在输出上优化哪些内容，以便让用户快速使用

压力测试工具通常伴随着大多数这些措施（内存，CPU和数据库使用除外），YSlow或Firebug在客户端上也是如此。

Answer 2

在分析负载测试的结果时，我们会查看各种各样的指标。

在服务器上，我们从这四个主要类别开始：

• CPU（利用率百分比，上下文切换/秒，进程队列长度）
• 内存（％使用，页面读取/秒，页面写入/秒）
• 带宽（传入，传出，发送和接收错误，＃连接，连接失败，段重传/秒）
• 磁盘（磁盘I / O时间％，平均服务时间，队列长度，读取和写入/秒）

我们还希望查看特定于正在使用的网络服务器和应用服务器的指标。例如，在IIS中我们查看IIS连接数，缓存命中率和周转频率等。在.NET中，我们将查看ASP.NET请求/秒，ASP.NET上次请求执行时间，ASP.NET当前请求，ASP.NET排队请求，ASP.NET请求等待时间，ASP.NET错误/秒等等。

在客户端，我们主要关注页面的总加载时间，关键事务的持续时间和TTFB（第一个字节的时间），带宽使用情况，平均页面大小和故障率。我们还发现两个指标非常有用 - 我们称之为等待用户和平均等待时间。没有多少工具具有这些功能 - 它们在每个采样周期告诉您从服务器检索资源的过程中有多少模拟用户以及他们平均等待资源到达的时间。我们发现这些对于

非常有用

• 确定服务器何时达到其容量
• 发现服务器已停止响应某些类型的请求（通常针对某些资源，例如需要数据库查询的资源）

Answer 3

另一项良好的健全性检查是至少24小时进行测试。我们这样做是因为一个应用程序运行了几个小时然后降级。发现了计划任务以及数据库连接池的一些问题。

Answer 4

网上有很多服务可以为您进行此类测试。当然，这种方法的一个缺点是，很难将服务中的数据（可以在外部观察到的内容）与您自己的内部数据（有关磁盘I / O，数据库操作等）相关联。如果您最终走这条路线，我建议找一家供应商，让您以编程方式访问原始测试结果数据。