培训负载testing的Web应用程序？

1. 首先，从业务代表开始。 他们（应该）最好地知道应用程序。 确定关键交易，以及端到端响应时间。 理想情况下，他们将能够给你一个文件，捕捉他们的非function性要求。 如果您的应用程序正在replace旧版应用程序，那就更好了 – 尽可能多地从该应用程序获取适用的使用情况度量标准。 这是性能testing最关键的成功因素。 了解潜在用户群的规模，可能同时使用的用户数量，同时执行的每个关键交易的＃％，每个[时间范围]的增长率。

2. 构build一个模拟关键事务的自动化脚本。 在这个脚本中包含思考时间。 通过您的应用程序/网站，很less有用户可以使用，而无需花几秒钟的时间来查看应用程序对input做出的回应。 如果没有充分模拟思考时间，可能会导致您对应用程序进行不切实际的加载，从而导致不愉快。 也就是说，企业可以确定10％的用户群是超级用户，而且您可能希望以90％的普通用户，“正常”的思考时间和10％的超级用户交付负载，速度更快，更具侵略性思考时间。

3. 在一段时间内（加速时间）添加您的虚拟用户 – 除非您真的有这种负载（销售开始于上午9:00！），否则不要在1秒内从0-500。 理解应用程序在负载峰值情况下的performance是很好的，但是在这些情况下，一些应用程序可能会失败，如果您期望这种负载，这只是一个问题。 否则，你可能会发现自己花费的钱比支持可能永远不会出现的负载要多得多。

4. 延迟和networking速度的因素。 对于压力testing来说，拥有一个千兆以太网连接是非常好的，延迟小于1毫秒，您可以使用它来推动您的应用程序以确定何时会失败。 但实际上，您的用户通常并不那么接近您的应用程序 – 他们正在通过所有不同types的networking条件。

5. 耐力testing – build议至less24小时，如果能负担得起，则更多。 您想要捕获定期批处理运行时（如备份，病毒定义更新，甚至IIS应用程序池回收（默认情况下每29小时）），应用程序发生的情况。

6. 了解性能testing和负载testing之间的区别。 负载testing通常会显示服务器的angular度。 这并不完全正确 – 许多工具会告诉你一个事务在TTLB方面的时间 – 但是今天的大多数工具并不反映客户端的渲染时间，这在JS大量的应用程序中是重要的，或者是使用XSLT ， 例如。

7. 不要单纯依靠你的自动化testing号码 – 至less不能从第一天开始。 定期手动validation你回来的号码。 随着时间的推移，你可以让自己变得更加自信。

8. 性能计数器 – 每一个应用程序会有所不同，但是你不会从四个基本的食物组–CPU，内存，磁盘I / O，networkingI / O开始出错。 我的首选计数器清单是在http://www.oneredlight.com/perf.config.txt。 您可以设置您的应用程序以使用以下命令行将这些计数器logging到一个300 MB的循环文件：logman create counter PERF -f bincirc -max 300 -si 2 -v -o“c：\ perflogs \ perf”-cf “perf.config”。 我只试过这些在Windows 2008 / IIS 7 / SQL 2008，所以你的里程可能会有所不同。 如果您的应用程序在MS堆栈上，我还build议阅读ht tp：//msdn.microsoft.com/en-us/library/ms998530.aspx。

（为破坏的url道歉;新用户无法发布超链接）