Justin Scott Asked: 2009-05-13 06:18:43 +0800 CST2009-05-13 06:18:43 +0800 CST 2009-05-13 06:18:43 +0800 CST 负载测试 Web 应用程序的培训？ 772 我们已经在 ServerFault 上讨论了用于负载 测试的工具，但是关于如何正确使用它们的培训呢？是否有专门从事涵盖负载测试的 IT 培训的公司？您如何正确地提出模拟负载？你应该运行多长时间的测试？测试运行时在服务器端跟踪的最佳指标是什么？等等... testing web-applications stress 1 个回答 Voted Best Answer JohnW 2009-05-31T13:07:21+08:002009-05-31T13:07:21+08:00 首先，从业务代表开始。他们（应该）最了解应用程序。确定关键事务和端到端响应时间。理想情况下，他们将能够向您提供一份包含其非功能性需求的文档。如果您的应用程序正在替换旧版应用程序，那就更好了 - 从该应用程序中获取尽可能多的适用使用指标。这是性能测试最关键的成功因素。了解潜在用户群的规模、可能同时使用它的用户数量、同时执行的每个关键事务的#%、每个 [时间范围] 的增长率。 构建一个模拟关键交易的自动化脚本。在此脚本中包含思考时间。很少有用户会在不花几秒钟时间查看应用程序响应他们的输入的情况下通过您的应用程序/网站启动。未能充分模拟思考时间可能会导致您的应用程序承受不切实际的负载，从而导致周围的不愉快。话虽如此，企业可能会确定 10% 的用户群是高级用户，您可能希望以 90% 的普通用户、“正常”思考时间和 10% 的高级用户、更快、更积极的方式交付负载思考时间。 在一段时间内（加速时间）添加您的虚拟用户 - 不要在 1 秒内从 0 到 500，除非您实际上会有这种负载（销售从上午 9:00 开始！）。了解您的应用程序在负载峰值下的行为是很好的，但某些应用程序可能会在这些情况下失败，如果您期望这种负载，这只是一个问题。否则，您可能会发现自己花费的钱比支持可能永远不会出现的负载所需的钱多得多。 延迟和网络速度的因素。对于压力测试，最好有一个延迟小于 1 毫秒的千兆以太网连接到您的应用程序，您可以使用它来推送您的应用程序以确定它何时会失败。但实际上，您的用户通常不会那么接近您的应用程序——他们会遇到所有不同类型的网络条件。 耐力测试 - 建议至少 24 小时，如果您负担得起，可以延长。您希望捕获定期批处理运行时应用程序发生的情况，例如备份、防病毒定义更新，甚至 IIS 应用程序池回收（默认每 29 小时）。 了解性能测试和负载测试之间的区别。负载测试通常会显示服务器的视角。这并不完全正确 - 许多工具会根据 TTLB 向您显示事务所花费的时间 - 但今天的大多数工具都没有反映客户端渲染时间，这在 JS 繁重的应用程序或使用 XSLT 的应用程序中很重要， 例如。 不要仅仅依靠你的自动化测试数字——至少不是从第一天开始。定期手动验证您返回的数字。随着时间的推移，您可以让这种情况消退，因为您对自己的模拟越来越有信心。 性能计数器 - 每个应用程序都会有所不同，但从四个基本食物组开始你不会出错 - cpu、内存、磁盘 i/o、网络 i/o。我的首选计数器列表位于 ht tp://www.oneredlight.com/perf.config.txt。您可以使用以下命令行将应用程序设置为将这些计数器记录到 300 MB 循环文件中： logman create counter PERF -f bincirc -max 300 -si 2 --v -o "c:\perflogs\perf" -cf “性能。配置”。我只在 Windows 2008/IIS 7/SQL 2008 上试过这些，所以你的里程可能会有所不同。如果您的应用程序位于 ms 堆栈上，我还建议您阅读 ht tp://msdn.microsoft.com/en-us/library/ms998530.aspx。 （为损坏的网址道歉；新用户无法发布超链接）
首先，从业务代表开始。他们（应该）最了解应用程序。确定关键事务和端到端响应时间。理想情况下，他们将能够向您提供一份包含其非功能性需求的文档。如果您的应用程序正在替换旧版应用程序，那就更好了 - 从该应用程序中获取尽可能多的适用使用指标。这是性能测试最关键的成功因素。了解潜在用户群的规模、可能同时使用它的用户数量、同时执行的每个关键事务的#%、每个 [时间范围] 的增长率。
构建一个模拟关键交易的自动化脚本。在此脚本中包含思考时间。很少有用户会在不花几秒钟时间查看应用程序响应他们的输入的情况下通过您的应用程序/网站启动。未能充分模拟思考时间可能会导致您的应用程序承受不切实际的负载，从而导致周围的不愉快。话虽如此，企业可能会确定 10% 的用户群是高级用户，您可能希望以 90% 的普通用户、“正常”思考时间和 10% 的高级用户、更快、更积极的方式交付负载思考时间。
在一段时间内（加速时间）添加您的虚拟用户 - 不要在 1 秒内从 0 到 500，除非您实际上会有这种负载（销售从上午 9:00 开始！）。了解您的应用程序在负载峰值下的行为是很好的，但某些应用程序可能会在这些情况下失败，如果您期望这种负载，这只是一个问题。否则，您可能会发现自己花费的钱比支持可能永远不会出现的负载所需的钱多得多。
延迟和网络速度的因素。对于压力测试，最好有一个延迟小于 1 毫秒的千兆以太网连接到您的应用程序，您可以使用它来推送您的应用程序以确定它何时会失败。但实际上，您的用户通常不会那么接近您的应用程序——他们会遇到所有不同类型的网络条件。
耐力测试 - 建议至少 24 小时，如果您负担得起，可以延长。您希望捕获定期批处理运行时应用程序发生的情况，例如备份、防病毒定义更新，甚至 IIS 应用程序池回收（默认每 29 小时）。
了解性能测试和负载测试之间的区别。负载测试通常会显示服务器的视角。这并不完全正确 - 许多工具会根据 TTLB 向您显示事务所花费的时间 - 但今天的大多数工具都没有反映客户端渲染时间，这在 JS 繁重的应用程序或使用 XSLT 的应用程序中很重要， 例如。
不要仅仅依靠你的自动化测试数字——至少不是从第一天开始。定期手动验证您返回的数字。随着时间的推移，您可以让这种情况消退，因为您对自己的模拟越来越有信心。
性能计数器 - 每个应用程序都会有所不同，但从四个基本食物组开始你不会出错 - cpu、内存、磁盘 i/o、网络 i/o。我的首选计数器列表位于 ht tp://www.oneredlight.com/perf.config.txt。您可以使用以下命令行将应用程序设置为将这些计数器记录到 300 MB 循环文件中： logman create counter PERF -f bincirc -max 300 -si 2 --v -o "c:\perflogs\perf" -cf “性能。配置”。我只在 Windows 2008/IIS 7/SQL 2008 上试过这些，所以你的里程可能会有所不同。如果您的应用程序位于 ms 堆栈上，我还建议您阅读 ht tp://msdn.microsoft.com/en-us/library/ms998530.aspx。
（为损坏的网址道歉；新用户无法发布超链接）