ASP.NET压力测试
原文地址：https://www.cnblogs.com/zhili/articles/StreeTool.html
前言
对于直接面对互联网用户的WEB应用，在开发设计的时候必须格外小心，因为谁也不知道在单位时间内WEB程序访问和运行的速度。所以，在程序设计完成以后，最后针对程序进行一些严格的甚至是苛刻的测试，以确定程序在复杂的网络环境和服务器高压负荷下是否可以保持正常和相对稳定的效率。 下面介绍ASP.NET中如何进行压力测试。
一、什么是压力测试
压力测试一般针对WEB应用进行，比如网站等。进行压力测试的目的是为了确定WEB应用在现实的网络环境中是否可以正确而安全的处理各种用户提交的不确定请求，检验程序的健壮性。
负压测试的另外一个目的在于故意提供足够多的请求，观察程序在这种情况下的反应能力。
二、为什么要压力测试
百度、谷歌搜索引擎不但搜索结果准确，而且，搜索速度更是奇快无比。搜索结果准确，那是程序算法在一个方面的表现，搜索速度快，则关系到整个系统的构件和程序的健壮行。如果希望自己编写的程序也可以在大访问量的情况下“从容不迫”，就有必要对程序进行负压测试。
对于访问量较大的网站或者程序，特别是提供一些比较热门话题程序，最好在正式将网站或者程序公布以前进行比较完备的负压测试，并且根据测试即使优化程序或者合理配置服务器硬件，这样网站不至于在用户量急剧增加的情况下出丑甚至崩溃。
三、压力测试中需要掌握的几个基本概念
1：吞吐率（Requests per second）
服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。
记住：吞吐率是基于并发用户数的。这句话代表了两个含义，1：吞吐率和并发用户数相关；2：不同的并发用户数下，吞吐率一般是不同的。
计算公式：总请求数 / 处理完成这些请求数所花费的时间，即
Request per second = Complete requests / Time taken for tests
2：并发连接数（The number of concurrent connections）
并发连接数指的是某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。
3：并发用户数（The number of concurrent users，Concurrency Level）
要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。在HTTP/1.1下，IE7支持两个并发连接，IE8支持6个并发连接，FireFox3支持4个并发连接，所以相应的，我们的并发用户数就得除以这个基数。
4：用户平均请求等待时间（Time per request）
计算公式：处理完成所有请求数所花费的时间/ （总请求数 / 并发用户数），即
Time per request = Time taken for tests /（ Complete requests / Concurrency Level）
5：服务器平均请求等待时间（Time per request: across all concurrent requests）
计算公式：处理完成所有请求数所花费的时间 / 总请求数，即
Time taken for / testsComplete requests
可以看到，它是吞吐率的倒数。
同时，它也=用户平均请求等待时间/并发用户数，即
Time per request / Concurrency Level
四、有效的压力测试系统将应用以下这些关键条件:
1、重复(Repetition)
或许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个 Web
服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品
是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。
2、并发(Concurrency)
并 发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多 Web
服务。这个原则不一定适用于所有的产品(比如无状态服务)，但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出
来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个
Web 服务压力测试需要一次模拟多个客户机。Web
服务(或者任何多线程代码)通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序(例如以特定的定时条件)执行时才会被发现。把这个原
则与重复原则结合在一起，您可以应用许多代码路径和定时条件。
3、量级(Magnitude)
压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个
Web
服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级
总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它。例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误(或者仅能发现功能上的缺陷)，
但与其他压力原则结合在一起时，您将可以增加发现问题的机会。
4、随机变化
最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生 命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的 Web 服务的顺序。使用并发，您可以改变一起执行的 Web 服务、同一时间运行的 Web 服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出现的变量(例如，发送各种大小的消息或数字输入值)。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。
五、Web 压力测试常用的工具
1 Siege -Siege（英文意思是围攻）是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每 个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。 Siege 支持基本的认证，cookies， HTTP 和 HTTPS 协议。
2. http_load – http_load 以并行复用的方式运行，用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。可以可以测试HTTPS类的网站请求。
3. Web Polygraph – Web Polygraph这个软件也是一个用于测试WEB性能的工具，这个工具是很多公司的标准测试工具，包括微软在分析其软件性能的时候，也是使用这个工具做为基准工具的。很多招聘测试员的广告中都注明需要熟练掌握这个测试工具。
4、微软的Web Application Stress
由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大 的压力测试工具，您可以使用少量的客户端计算机仿真大量用户上线对网站服务所可能造成的影响，在网站实际上线之前先对您所设计的网站进行如同真实环境下的 测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。
5、LoadRunner
LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ， 企业能最大限度地缩短测试时间， 优化性能和加速应用系统的发布周期。企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢， 系统崩溃等问题。这些都不可避免地导致公司收益的损失。
LoadRunner 能让企业保护自己的收入来源， 无需购置额外硬件而最大限度地利用现有的IT 资源， 并确保终端用户在应用系统的各个环节中对其测试应用的质量， 可靠性和可扩展性都有良好的评价。
LoadRunner 是一种适用于各种体系架构的自动负载测试工具， 它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统， 它通过模拟实际用户的操作行为和实行实时性能监测， 来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术， 为您的特殊环境提供特殊的解决方案。
