负载测试的注意事项
本主题提供了在 Visual Studio 旗舰版 中执行大型负载测试的一些技巧。 讨论了下列主题：
选择适当的负载模式
选择适当的连接模型
采样速率和数据收集
思考时间
为 Web 性能测试请求设置响应时间目标
包括计时详细信息以收集百分比数据
设置“新用户的百分比”属性
启用 ASP.NET 探查器
启用虚拟用户日志记录
启用 SQL 跟踪
保持适当的代理计算机数
选择适当的负载模式
负载模式分为三种：常量负载模式、分级负载模式和基于目标的负载模式。 若要为负载测试选择适当的负载模式，必须了解每种模式的优点。 有关更多信息，请参见编辑负载模式以便为虚拟用户活动建模。
常量 |
如果希望长时间内采用不变的用户负载运行负载测试，常量负载模式很有用。 如果为常量负载模式指定较高的用户负载，那么建议还要为负载测试指定预热时间。 如果指定了预热时间，便可以避免因成百上千个新用户会话同时命中站点而造成压力过大。 |
步骤 |
分级负载模式是最常用且最有用的负载模式之一，因为在该模式下可以随着用户负载的增长监视系统的性能。 通过随着用户负载的增长监视系统，可以确定响应时间处于可接受程度时所能支持的用户数，或者反过来确定当性能变得不可接受时的用户数。 如果每一步均添加大量用户（例如，超过 50 个用户），则考虑使用“单步负载增加时间”属性在步骤中交错启动用户。 有关更多信息，请参见如何：为分级负载模式指定单步负载增加时间属性。 |
基于目标的负载模式 |
基于目标的负载模式与分级负载模式的类似之处是用户负载通常会随时间增长，不过基于目标的负载模式允许您指定当某些性能计数器达到一定水平时负载应停止增长。 例如，可以使用基于目标的负载模式持续增长负载，直至目标服务器之一的占用率达到 75%，然后保持负载稳定。 |
如果预定义的负载模式无法满足需求，那么还可以实现自定义负载测试插件，以便在负载测试运行时控制用户负载。 有关更多信息，请参见为负载和 Web 性能测试创建和使用自定义插件。
选择适当的 Web 性能测试连接模型
负载测试运行设置提供不同的选项，支持使用**“Web 测试连接模型”**属性建模用户与 Web 服务器的连接。 连接模型分为三种：每个用户专用连接模型、连接池模型和每个测试迭代专用连接模型。 若要为负载测试选择适当的连接模型，必须了解每种模型的优点。
每个用户专用连接 |
每个用户专用连接模型最为逼真地模拟了真实浏览器的行为。 每个运行 Web 性能测试的虚拟用户最多使用六个与每个 Web 服务器的连接。 对于专用于该虚拟用户的 Web 服务器，连接一直保持打开状态。 当在 Web 性能测试中发出第一个请求时，即建立第一个连接。 当页中包含多个从属请求时，可能会用到其他连接。这些请求可能使用其他连接并行发出。 旧式浏览器对于每个 Web 服务器最多使用两个连接，但 FireFox 3 和 Internet Explorer 8 对于每个 Web 服务器最多使用 6 个连接。 在整个负载测试中对虚拟用户重用这些相同的连接。 每个用户专用连接模型的缺陷在于，代理计算机上保持打开的连接数可能很大（可达用户负载的六倍，如果面向多个 Web 服务器，甚至更大），而且支持这么大连接数所需的资源可能会限制可由单个负载测试代理驱动的用户负载。 |
连接池 |
连接池模型在多个虚拟 Web 性能测试用户之间共享 Web 服务器的连接，从而节约负载测试代理上的资源。 在连接池模型中，连接池大小指定了负载测试代理与 Web 服务器之间的最大连接数。 如果用户负载大于连接池大小，则代表不同虚拟用户运行的 Web 性能测试将共享同一连接。 这是用于驱动应用层的大多数负载的最佳模型。 共享连接意味着，当一个 Web 性能测试正在使用连接时，另一个 Web 性能测试可能必须等待才能发出请求。 负载测试性能计数器“平均连接等待时间”将跟踪 Web 性能测试在提交请求之前的平均等待时间。 此数字应小于页的平均响应时间。 否则，连接池大小可能会太小。 |
每个测试迭代专用连接 |
每个测试迭代专用连接在每次测试迭代后关闭连接，并在下一次迭代时打开新连接。 此设置将对您的网络登录带来非常大的压力。 除非要求使用此选项，否则建议您使用前面两个选项之一。 |
采样速率和数据收集
根据负载测试的长度选择适当的采样速率。 采样速率越小（如 5 秒），收集的每个性能计数器的数据就越多。 长时间收集大量的数据可能会引起磁盘空间错误。 对于长的负载测试，可以提高采样速率以减少收集的数据量。 性能计数器的数量也会影响收集的数据量。 对于进行测试的计算机，减少计数器的数量将减少收集的数据量。
您必须进行试验，以确定最适合您的特定负载测试的采样速率。 不过，您可以从下表提供的建议采样速率开始操作。
负载测试持续时间 |
建议的采样速率 |
|---|---|
< 1 小时 |
5 秒 |
1 - 8 小时 |
15 秒 |
8 - 24 小时 |
30 秒 |
> 24 小时 |
60 秒 |
思考时间
Web 性能测试请求的思考时间对响应时间处于合理程度下所能支持的用户数具有较大的影响。 一般而言，将思考时间从 2 秒更改为 10 秒会使可以模拟的用户数增长到原来的 5 倍。 但是，如果您的目标是模拟真实的用户，则应当根据用户在网站上的行为方式来设置思考时间。 增大思考时间和用户数不一定会给 Web 服务器带来更大的压力。 如果网站会进行身份验证，则所用的方案类型将影响性能。
如果禁用 Web 性能测试的思考时间，那么可能能够生成在每秒请求数方面具有较大吞吐量的负载测试。 如果禁用思考时间，则还应当将用户数减少到比启用思考时间时的用户数少得多的水平。 例如，如果禁用思考时间并尝试运行 1000 个用户，那么无论是目标服务器还是负载测试代理，都很可能会过载。
有关更多信息，请参见编辑思考时间以在负载测试方案中模拟网站上的人机交互延迟。
为 Web 性能测试请求设置响应时间目标
Web 测试请求的属性之一是响应时间目标。 如果为 Web 性能测试请求定义响应时间目标，那么当在负载测试中运行 Web 性能测试时，负载测试分析器将报告响应时间未达到目标的 Web 性能测试的百分比。 默认情况下，不为 Web 请求定义响应时间目标。
此外，如果您使用“响应时间目标”验证规则，则不满足响应时间目标的页将导致负载测试出错。 如果您使用错误日志，可以看到页面变得缓慢时虚拟用户正在执行的操作。
有关更多信息，请参见如何：在 Web 性能测试中设置页面响应时间目标。
包括计时详细信息以收集百分比数据并启用详细信息视图
运行设置包括一个名为**“计时详细信息存储”的属性。 如果启用此属性，则在负载测试过程中执行各个测试、事务和页所需的时间都将存储在负载测试结果存储库中。 这将在负载测试分析器中启用虚拟用户活动图。 这还使得 90%、95% 和 99% 的数据以及标准偏差显示在负载测试分析器的“测试”、“事务”和“页”**表中。
默认情况下，启用**“计时详细信息存储”**属性，使用负载测试分析器在负载测试结果的“详细信息”视图中支持虚拟用户活动图。
您应考虑对大型测试禁用**“计时详细信息存储”**属性。 这样做有两个重要的原因：
负载测试结果存储库中存储计时详细信息数据所需的空间可能会非常大，尤其是对于较长的负载测试。
在负载测试结束时将此数据存储到负载测试结果存储库中所需的时间很长，因为在负载测试完成执行之前此数据一直存储在负载测试代理上。
如果负载测试结果储存库中可用的磁盘空间足够大，那么可以启用**“计时详细信息存储”以获得百分比数据。 启用“计时详细信息存储”有两个选项：“StatisticsOnly”和“AllIndividualDetails”。 无论采用哪个选项，所有单个测试、页和事务均会计时，且根据单个计时数据来计算百分比数据。 如果选择“StatisticsOnly”，则在计算完百分比数据之后，从储存库中删除单个计时数据。 删除数据可以减少储存库中所需的空间量。 不过，如果要使用 SQL 工具直接处理计时详细信息数据，或允许在虚拟用户活动图中查看虚拟用户详细信息，则可以选择“AllIndividualDetails”**，以将计时详细信息数据保存在存储库中。
有关更多信息，请参见在负载测试分析器的详细信息视图中分析负载测试虚拟用户活动和如何：将负载测试配置为收集完整详细信息，以便在测试结果中启用虚拟用户活动。
设置“新用户的百分比”属性
负载测试中的每个方案都具有名为**“新用户的百分比”**的属性。 此属性会影响负载测试运行时引擎对 Web 浏览器执行的缓存的模拟方式。 **“新用户的百分比”**的默认值为 0。 这意味着每个虚拟用户均保留两次测试迭代之间的从属请求虚拟缓存和 Cookie 列表。 缓存工作方式类似于浏览器缓存，因此将不会对 URL 进行后续请求，这最为逼真地模拟了真实 Web 浏览器。
如果将“新用户的百分比”设置为 100%，则每个用户实际上都是“一次用户”，永远不会返回网站。 在这种情况下，负载测试中运行的每次 Web 性能测试迭代都被视为用户第一次访问网站，这些用户的浏览器在以前的访问中缓存的内容中没有来自网站的任何内容。 因此，将下载 Web 性能测试中的所有请求，包括所有从属请求（如图像）。
提示
但存在一种例外情况，即当 Web 性能测试中多次请求同一个可缓存资源时。
使用 0% 新用户的默认值驱动网站的应用层的大多数负载。 这不仅最为逼真地模拟真实用户，还将驱动发生多数性能问题的应用层的更多负载。 有关更多信息，请参见如何：指定使用 Web 缓存数据的虚拟用户的百分比。
启用 ASP.NET 探查器
ASP.NET 探查器诊断数据适配器是 Microsoft Visual Studio 2010 中的一项新功能，利用此功能，可以在运行负载测试时从应用层收集 ASP.NET 探查器数据。 不能对较长的负载测试（例如，运行时间超过一小时的负载测试）运行探查器，因为探查器文件会很大（几百兆）。 应使用 ASP.NET 探查器运行较短的负载测试，从而仍具有深入诊断性能问题的优点。
有关更多信息，请参见如何：使用测试设置为负载测试配置 ASP.NET 探查器。
启用虚拟用户日志记录
这是 Microsoft Visual Studio 2010 中的一项新功能，让您可以收集有关失败测试的完整日志或指定记录测试的频率。 日志记录由**“测试未通过时保存日志”、“为已完成测试保存日志的频率”和“最大测试日志数”属性控制。 收集的日志数由“最大测试日志数”和“为已完成测试保存日志的频率”属性设置控制。 默认设置会阻止收集大量日志。 对于将生成数百万条请求的长时间运行的测试，不要使用“为已完成测试保存日志的频率”设置，否则日志数会变得太大。 此外，将“最大测试日志数”**属性设置（实际控制每个错误类型的最大日志数）保持为一个合理的数字。 您应保留这些设置以防止收集几万条日志，因为这将增加测试结束时收集日志的时间，也将占用负载测试数据库的存储空间。
有关更多信息，请参见修改负载测试记录设置。
启用 SQL 跟踪
运行设置包括一个名为**“已启用 SQL 跟踪”的属性。 通过此属性，可以在负载测试期间启用 Microsoft SQL Server 的跟踪功能。 这是在运行负载测试时启动单独的 SQL Profiler 会话来诊断 SQL 性能问题的替代方法。 如果启用此属性，则负载测试分析器中将显示 SQL 跟踪数据。 可以在“表”页的“SQL 跟踪”**表中查看该数据。
若要启用此功能，则运行负载测试的用户必须具有执行 SQL 跟踪所需的 SQL 特权。 如果使用测试代理和测试控制器在远程计算机上运行负载测试，则控制器用户必须具有 SQL 特权。 此外，还必须指定写入跟踪数据文件的目录，通常为网络共享。 完成负载测试时，跟踪数据文件将导入负载测试存储库中，并与负载测试关联，以便稍后能使用负载测试分析器进行查看。
有关更多信息，请参见配置负载测试运行设置和如何：使用负载测试编辑器集成 SQL 跟踪数据。
保持适当的代理计算机数
如果代理计算机的 CPU 使用率超过 75%，或可用的物理内存低于 10%，则该计算机负载过度。 可以向测试控制器添加更多的代理计算机，以确保代理计算机不会成为负载测试的瓶颈。
有关更多信息，请参见使用测试控制器和测试代理在多台测试计算机之间分发负载测试和如何：指定要在负载测试方案中使用的测试代理。
请参见
任务
概念
其他资源
Consideration for Load Tests that Contain Web Performance Tests