负载测试网络应用程序
在对基本 Web 应用程序进行负载测试时，除了预期响应时间之外，您还会进行哪些健全性检查？
要求峰值内存使用情况公平吗？
您还进行哪些其他检查？
When load testing a basic web application, what sanity checks do you do other than expected response time?
Is it fair to ask for peak memory usage?
What other checks do you make?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在服务器上，
在客户端上
压力测试工具通常附带大多数这些措施（内存、CPU 和数据库使用情况除外），就像 YSlow 或 Firebug 在客户端上所做的那样。
On the server
On the client
Stress testing tools usually come with most of these measures (except for Memory, CPU and database usage), as do YSlow or Firebug do on the client.
在分析负载测试结果时，我们会考虑各种各样的指标。
在服务器上，我们从这 4 个主要类别开始：
我们还喜欢查看特定于 Web 服务器和应用程序服务器的指标使用。例如，在 IIS 中，我们查看 IIS 连接计数、缓存命中率和周转频率等。在 .NET 中，我们将查看 ASP.NET 请求数/秒、ASP.NET 最后请求执行时间、ASP.NET 当前请求数、ASP.NET 排队请求、ASP.NET 请求等待时间、ASP.NET 错误/秒等等。
在客户端，我们主要关注页面的总加载时间、关键事务的持续时间和 TTFB（第一个字节的时间）、带宽使用情况、平均页面大小和故障率。我们还发现两个非常有用的指标 - 我们称之为等待用户和平均等待时间。没有多少工具具有这些功能 - 它们在每个采样周期准确地告诉您有多少模拟用户正在从服务器检索资源，以及他们平均等待资源到达的时间。我们发现这些对于
We look at a pretty wide variety of metrics when analyzing the results of a load test.
On the server, we start with these main 4 categories:
We also like look at metrics specific to the webserver and application server in use. For example, in IIS we look at IIS connection counts, cache hit rates and turnover frequency, etc. In .NET, we would be looking at ASP.NET Requests/sec, ASP.NET Last Request Execution Time, ASP.NET Current Requests, ASP.NET Queued Requests, ASP.NET Request Wait Time, ASP.NET Errors/sec and many others.
On the client side, we are primarily looking at total load time for the pages, duration and TTFB (time to first byte) for critical transactions, bandwidth usage, average page size and failure rate. We also find two metrics very useful - we call them Waiting Users and Average Wait Time. Not many tools have these - they tell you at each sample period exactly how many simulated users are in the process of retrieving a resource from the server and how long, on average, they have been waiting for the resource to arrive. We find these very useful for
另一个好的健全性检查是运行测试至少 24 小时。我们这样做是因为一个应用程序运行良好几个小时，然后就降级了。发现计划任务和数据库连接池的一些问题。
Another good sanity check is to run the tests for at least 24 hours. We do that because one app ran nicely for a few hours then degraded. Discovered some issues with scheduled tasks as well as db connection pooling.
有许多在线服务也可以为您进行此类测试。当然，这种方法的缺点之一是很难将来自服务的数据（可以从外部观察到的数据）与您自己的有关磁盘 I/O、DB 操作等的内部数据关联起来。如果您最终走这条路，我建议找到一个供应商，让您能够以编程方式访问原始测试结果数据。
There are a number of services online that can do this type of testing for you as well. Of course, one of the downsides to this approach is that its harder to correlate the data from the service (which is what can be observed externally) with your own internal data about disk I/O, DB ops, etc. If you end up going this route I would suggest finding a vendor that will give you programmatic access to the raw test result data.