单一个中间件又分web中间件（apache 、IIS），应用中间件（tomcat 、weblogic 、webSphere ）等，虽然都是中间件，每一样拎出来往深了学都不是一朝一夕之功。但调优对于每一项的要求又不仅仅是“知道”或“会使用”这么简单。起码要达到“如何更好的使用”。

　　常看到性能测试书中说，性能测试不单单是性能测试工程师一个人的事儿。需要DBA 、开发人员、运维人员的配合完成。但是在不少情况下性能测试是由性能测试人员独立完成的，退一步就算由其它人员的协助，了解系统架构的的各个模块对于自身的提高也有很大帮助，同进也更能得到别人的尊重。

　　再说性能调优之前，我们有必要再提一下进行测试的目的，或者我们进行性能测试的初衷是什么？

能力验证：验证某系统在一定条件具有什么样的能力。

能力规划：如何使系统达到我们要求的性能能力。

应用程序诊断：比如内存泄漏，通过功能测试很难发现，但通过性能测试却很容易发现。

性能调优：满足用户需求，进一步进行系统分析找出瓶颈，优化瓶颈，提高系统整体性能。

http://www.cnblogs.com/fnng/archive/2012/07/31/2617546.html 

性能测试工具的选择与评估                                              

　　在性能工具原理与架构一章中，我们了解到性能测试工具的原理通常是：通过录制、回放脚本，模拟多用户同时访问被测试系统，模拟产生负载压力，监控并记录各种性能指标，生成性能分析结果和报告，从而完性能测试的基本任务。

　　对需要进行性能测试的组织来说，决定使用哪种性能测试工具也不是一个简单的问题。我们有需要对性能需求进行分析，购买成本，人员学习使用成本进行综合考虑，从而确定最适合的本次性能测试的工具。

注：这里所提到的性能测试工具为狭义上的性能测试工具，特指包含脚本生成、负载生成与测试数据搜集的性能测试工具，从广义上来讲，在性能测试过程中所用到一切工具，都可以称为性能测试工具，其中包括，软件协议分析工具，测试数据生成工具，测试监控工具等都属于性能测试工具范畴。

　　我简单的软件性能测试工具分为三类，商业收费工具、开源免费工具、自主开发工具。下面是这三类工具的比较：

通过上面的比较分析，很难判别对某类工具的取舍，各自有其明显的优势，当然也有明显的缺点，如何更好选择工具，这里就要结合实际性能的需求了。

需要考虑以下几个方面：

性能需求：

　　首先要考虑的是否满足性能需求，例如系统的协议不支持，无法创建脚本，系统的模拟用户数达不到，或都某此特殊功能无法测试，如流媒体性能测试等。一些有性能工具是无法满足这些需求的，那当然要首先排除。

购买成本：

　　对于商业工具的购买成本也是我们需要考虑的问题，其实，这个问题也是老板需要考虑的问题，对性能测试成本的整体预算等。当然了，在满足性能需求的前提下，当然一切从简。如果只需要某商业软件的部分功能，也可以只购买部分功能。有的是根据支持协议的多少、并发用户上限来区分，如loadrunner 。

　　这里要多扯一点，loadrunner应该是性能测试领域的巨无霸，它的年服务费多百万，这不是一般的小公司能承受的，可能许多网友用破解习惯了不以为然。而且loadrunner是可以定制的，一般商业软件都是可以定制的，也就是说，你有特定的需求，只要你愿意花钱，提供商都可以帮你定制开发。这样算下来成本会很高。

　　那么开源软件呢？ 开源的性能测试工具其实非常的多，因为它们都分别适合在不同的需求场景下，所以，它们的体积相比商业软件会小很大，当然功能也相对简陋。但是他们在某些情况下可以完全满足某些性能需求，或者可以通过几款开源工具配合满足，或者通过对开源工具进行扩展进行满足。对开源工具进行扩展，对测试人员的要求较高。需要测试人员对工具的原理及源代码有相当有研究。这里对测试人员自动能力的提升非常有帮助。

　　或者你的性能测试项目特殊，找遍市面上的所有性能工具无一款满意，商业定制成本过高。或者你想构建自己有工具体系。处于公司需求的特殊性与长期性考虑，可以自主开发一个性能测试工具来用。一次开发，永久收益（当然也需要维护与升级、扩展等），而且更贴近自已的需求。目前很多知明的大公司都有自己的性能测试工具，用于内部使用。 

人员学习成本：

　　最后要提到的就是人员对工具的学习成本，其实，测试人员在选择性能测试工具时最先考虑的就是从自己会使用的工具入手，这样可以最低的控制学习成生，如果整一个工具，测试人员单学测试脚本就学了半年，老板早让你走人了。这也是对性能测试人员要求较高的地方。所以，对于性能测试人员，你最好熟悉一款流程的商业性能工具，一款开源免费性能具，还需要熟悉常见的性能脚本开发语言等，这是基本要求。

性能测试工具介绍                                                                      

商业工具 ：

　　QA Load：Compuware公司的QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。QALoad是QACenter性能版的一部分，它通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能。QACenter汇集完整的跨企业的自动测试产品，专为提高软件质量而设计。QACenter可以在整个开发生命周期、跨越多种平台、自动执行测试任务。

    SilkPerformer：一种在工业领域最高级的企业级负载测试工具。它可以模仿成千上万的用户在多协议和多计算的环境下工作。不管企业电子商务应用的规模大小及其复杂性，通过SilkPerformer，均可以在部署前预测它的性能。可视的用户化界面、实时的性能监控和强大的管理报告可以帮助我们迅速的解决问题，例如加快产品投入市场的时间，通过最小的测试周期保证系统的可靠性，优化性能和确保应用的可扩充性。

     LoadRunner：一种较高规模适应性的，自动负载测试工具，它能预测系统行为，优化性能。LoadRunner强调的是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的确认和查找问题。此外，LoadRunner 能支持最宽范的协议和技术，为您的特殊环境，量身定做地提供解决方案。

　　WebRunner：是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能，用户创建的是基于javascript的测试脚本，称为议程agenda，用它来模拟客户的行为，通过执行该脚本来衡量web应用程序在真实环境下的性能。

　　IBM Rational Performance Tester（简称 RPT）也是一款性能测试工具，适用于基于 Web 的应用程序的性能和可靠性测试。Rational Performance Tester 将易用性与深入分析功能相结合，从而简化了测试创建、负载生成和数据收集，以帮助确保应用程序具有支持数以千计并发用户并稳定运行的性能。 

 开源或免费工具：

　　Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。 它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库， FTP 服务器, 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来在不同压力类别下测试它们的强度和分析整体性能。 

　　AutoBench 是一款基于httperf的Perl脚本。它会在一次测试中调用多次httperf来对web服务器进行测试，每次会按照给定的参数增加并发连接数，将 httperf的测试结果保存为CSV格式的文件，该文件可以被Excel直接读取，方便生成测试报告。借助于autobench自带的 bench2graph工具可以生成漂亮的测试结果对比图。 

　　ApacheBench 工具程式(ab)是 Apache 网站伺服器软体的一个附带的工具软体，专门用来执行网站伺服器的运行效能，特别是针对 Apache 网站伺服器 的效能分析。这支程式原本是用来检测 Apache 网站伺服器(Web Server) 所能够提供的效能，特别是可以看出 Apache 网站伺服器能提供每秒能送出多少网页，当然的，也可以用在任何其他的网站伺服器 Apache ab的全称是ApacheBench，是 Apache 附带的一个小工具，专门用于 HTTP Server 的benchmark testing，可以同时模拟多个并发请求。 

　　curl-loader（也被称为“omes-NIK”和“davilka”）是一个开源的C语言编写的工具，模拟应用负载和成千上万的几十万人的HTTP / HTTPS和FTP/ FTPS的客户端应用程序的行为，每个有其自己的源IP地址。相反，其他curl-loader使用真正的C编写的客户端协议栈，即libcurl和TLS/ openssl的SSL的HTTP和FTP协议栈，支持登录和验证口味和模拟用户行为的工具。 

　　Iago 是一个网站负载测试工具，Iago 针对一个给定的网站进行访问录制并合成流量数据。它不同于其他的负载生成工具，它试图保持恒定的请求率。例如如果你想按每分钟100K来请求您的服务，Iago 会试图保持这个速度进行测试。 

　　Pylot 是一款开源的用以测试 Web Service性能和扩展性的工具，它运行HTTP负载测试，这对于制定容量计划、确定基准点、分析系统瓶颈以及系统调优都非常有用。在使用过程 中，Pylot会发起并发请求（HTTP Requests），检验服务器响应，以及带有相关指标的报表。它通过GUI或者Shell/Console来执行和监视对被测试网站的测试过程。

-----------------------------------------------

 关于性能测试工具非常的多，如果你是个开源的粉丝可以去开源中国转转，那里有许多非常优秀的开源软件。

 目前市场上的性能测试的工具种类很多，可以简单的划分为以下几种：负载压力测试工具、资源监控工具、故障定位工具以及调优工具。

    1. 主流负载性能测试工具

    负载性能测试工具的原理通常是通过录制、回放脚本、模拟多用户同时访问被测试系统，制造负载，产生并记录各种性能指标，生成分析结果，从而完成性能测试的任务。

    主流的负载性能测试工具有：

    QA Load：Compuware公司的QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。QALoad是QACenter性能版的一部分，它通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能。QACenter汇集完整的跨企业的自动测试产品，专为提高软件质量而设计。QACenter可以在整个开发生命周期、跨越多种平台、自动执行测试任务。

    SilkPerformer：一种在工业领域最高级的企业级负载测试工具。它可以模仿成千上万的用户在多协议和多计算的环境下工作。不管企业电子商务应用的规模大小及其复杂性，通过SilkPerformer，均可以在部署前预测它的性能。可视的用户化界面、实时的性能监控和强大的管理报告可以帮助我们迅速的解决问题，例如加快产品投入市场的时间，通过最小的测试周期保证系统的可靠性，优化性能和确保应用的可扩充性。

    LoadRunner：一种较高规模适应性的，自动负载测试工具，它能预测系统行为，优化性能。LoadRunner强调的是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的确认和查找问题。此外，LoadRunner 能支持最宽范的协议和技术，为您的特殊环境，量身定做地提供解决方案。

    WebRunner：是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能，用户创建的是基于javascript的测试脚本，称为议程agenda，用它来模拟客户的行为，通过执行该脚本来衡量web应用程序在真实环境下的性能。

    免费测试工具：

    OpenSTA：开源项目，功能强大，自定义功能设置完备，但设置通过Script来完成。必须学习Script编写

    WAS（Web Application Stress Tool）：微软的工具，输出结果是纯文本的。

    主流商用负载性能工具的比较图如下：

    2.资源监控工具

    资源监控作为系统压力测试过程中的一个重要环节，在相关的测试工具中基本上都有很多的集成。只是不同的工具之间，监控的中间件、数据库、主机平台的能力以及方式各有差异。而这些监控工具更大程度上都依赖于被监控平台自身的数据采集能力，目前的绝大多数的监控工具基本上是直接从中间件、数据库以及主机自身提供的性能数据采集接口获取性能指标。

    首先，不同的应用平台有自身的监控命令以及控制界面。比如UNIX主机用户可以直接使用topas，vmstat,iostat了解系统自身的健康工作状况。另外，weblogic以及websphere平台都有自身的监控台，在上面可以了解到目前的JVM的大小、数据库连接池的使用情况以及目前连接的客户端数量以及请求状况等等。只是这些监控方式的使用对测试人员有一定的技术储备要求，需要自己熟练掌握以上监控方式的使用。

    第三方的监控工具相应的对一些系统平台的监控进行了集成。比如Loadrunner对目前常用的一些业务系统平台环境都提供了相应的监控入口，从而可以在并发测试的同时，对业务系统所处的测试环境进行监控，更好的分析测试数据。

    但Loadrunner工具其提供的监控方式还不是很直观，一些更直观的测试工具能在监控的同时提供相关的报警信息，类似的监控产品如QUEST公司提供的一整套监控解决方案包括了主机的监控、中间件平台的监控以及数据库平台的监控。QUEST系列监控产品提供了直观的图形化界面，能让测试者尽快进入监控的角色。

    3. 故障定位工具以及调优工具

    技术的不断发展以及测试需求的不断提升，故障定位工具应运而生，它能更精细的对负载压力测试中暴露的问题进行故障根源分析。在目前的主流测试工具厂商中，都相应地提供了对应的产品支持。尤其是目前.NET以及J2EE架构的流行，测试工具厂商纷纷在这些领域提供了相关的技术产品，比如Loadrunner模块中添加的诊断以及调优模块、Quest公司的PerformaSure、Compuware的Vantage套件以及CA公司收购的Wily的Introscope工具等等，都在更深层次上对业务流的调用进行追踪。这些工具在中间件平台上引入探针技术，能捕获后台业务内部的调用关系，发现问题所在，为应用系统的调优提供直接的参考指南。

    在数据库产品的故障定位分析上，Oracle自身提供了强大的诊断模块，同时，Quest公司的数据库产品也在数据库设计、开发以及上线运行维护都提供了全套的产品支持。

　上一章节中我们对性能的需求进行了分析，知道了测试对象，了解了测试需求，那么下面就需要制定一份详细的计划，来规划和指导性能测试工作的进行。为了使你对性能测试计划更清晰明白，这里以测试计划的格式来描述。

一．简介

　　简介部分就不用过多描述了，无非项目的背景，进行此次性能测试的原因，以及性能测试覆盖的范围等等，几乎所有项目文档都在开端对项目进行简单的阐述。

二．性能测试需求

寻找的被测试对象和压力点

　　要测试的对象不是凭空想象出来，而是经过分析与系统数据收集得到。下取几个典型的压力点

登录：对于一般的系统来说，登录是用户操作系统的前提，如果用户根本就登录不了，那么其它功能将毫无用处。例如网游戏，开新服的时候，玩家挤破了脑袋只为登录。

查询：查询一般比较消耗系统和数据库资源。搜索引擎的查询功能就是典型，如果你在输入框内输入内容，很久就得不到结果。我想被称为“互联网入口”的搜索引擎就不会存在。

交易：对于一些电子商务系统来说，交易过程的性能要求是很高的，如果交易过程消耗用户很长时间的话。我宁愿去超市买东西了。当然，除了交易速度外，对交易的成功率要求也是非常高的。不然，造成的损失也是不可估量的。

被测的系统应该是最重要的最基本的功能，也是用户使用最频繁的功能。

一般的性能要求包括：

系统容量：系统最大容纳多少个用户注册。

访问数：同时访问系统的用户数。

并发数：一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户）。

系统的最大用户数与最佳用户数:系统在承受的最大并发用户数量，系统在最佳状态下承受的并发用户数据。

响应时间：用户提交一个操作到得到响应的时间间隔。

吞吐率：系统每秒钟处理的TPS

　　性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的性能。并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行3个月的数据量。

　　在描述并发用户数目时，总是会带有相应的时间段限制。系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。单位时间内能处理的请求个数就是系统的业务吞吐量。虚拟并发用户的数量可以使用如下的公式换算： （真实用户数×每个真实用户请求数）/(总请求响应时间+真实用户总思考时间)=(虚拟用户数×每用户请求个数)/(总请求响应时间+虚拟用户总思考时间)=吞吐量。

如何获得有效的需求

1、客户方提出

　　客户方能提出明确的性能需求，说明对方很重视性能测试，这样的企业一般是金融、电信、银行、医疗器械等；他们一般对系统的性能要求非常高，对性能也非常了解。提出需求也比较明确。

　　曾经有一个银行项目，已经到最后的性能测试极端，因为数据库设计不合理，导致性能出现很大的问题，最终不得不把整合项目作废，对于这样的项目，其实从分析设计阶段就应该考虑系统的性能问题。性能测试也一样，对于某些项目来说越早进行越好。当然，前期的性能测试为单元性能测试、接口性能测试，有别系统性能测试。

　　有时候也会碰到不懂装懂的客户，提出一些无理的需求，比如只能2000人使用的OA系统，客户要求并发用户2000，这显然是不合理的需求。这个就要看你怎么给客户沟通了。但是，千万别伪造数据欺骗客户。

2、根据历史数据分析

　　对于一些面向用户的独特产品，比较难定位市场的大小，可以先上一运营一段时间，通过运营可以搜集客户资料，比如，每月、每星期、每天的峰值业务量是多少。用户以 什么样的速度在递增中。用户对系统的哪些功能模块使用的最多，他们所点的比例等等。

　　收集到这些数据之后，我们就可评估系统的系统需求指标，从而进行性能测试。

3、需求分析与定位

　　这里根据前期的需求分析与定位，来分析确定系统性能指标。例如某省幼儿园管理系统。统计全省有多少家幼儿园，系统的使用时间为幼儿到校之后，管理人员对幼儿的到校情况进行录入，以及幼儿的午饭，放学情况的录入时间。经过与需求人员交流分析也能得到比较明确的性能指标。

4、参考历史项目或其它同行业的项目

　　如果公司之前有类似的项目经验，根据项目大小及上次性能测试的一些指标。从根据项目的规模可以制定出相应的性能指标。

　　即使本公司没有类似的项目，但其它公司有类似的项目，例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。 

5、参考其它资料数据

　　如果你做的是非常独特的产品，市场上没有此类型的产品，而且需求及市场也难以估计，那么只能从与产品相关的资料中寻找痕迹了。不过，相信这样不确定性的产品，老板要承担的风险也是挺大的。^_^

　　需要说明的是，我上面介绍的方面并非是独立的，可以综合的使用，你可以根据客户提出的指标，再根据历史数据以及参考同类型项目来进行。这样可以更确定你的性能指标是客户（或自己）真正需要的、最符合项目需求的。

性能测试点的选取

*　　发生频率非常高的（例如：某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上）

*　　关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）

*　　资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）

对性能需求点的描述

准确

如**系统必须在不超过 10 秒的响应时间内,处理 20 起登录任务。再如发邮件时间最大不超过5秒以及平均时间在2秒以内。

一致

用户和性能测试工程师对有关术语的理解要一致,如:并发用户数、在线用户数、注册用户数: 

特定

性能测试的需求一定是有条件的。

检查系统后台关键业务数据10G、操作数据量为20K, 1500 个用户、500 个并发用户运行的负载下，连续运行12小时过程中,业务操作是否满足性能需求。

常见性能需求

1、WEB首页打开速度5s以下，web登陆速度 15s以下。

2、邮件服务支持50万个在线用户

3、计费话单成功率达到99.999%以上。

4、在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS

5、系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时 

6、这个系统能否支撑200万的vu（每天登录系统的人次）          vu----Virtual user(虚拟用户) 

"不成文"的性能需求指标：　　

响应时间：根据国外的一些资料，一般操作的响应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。

　　Peter bickford 在调查用户反应时发现：在连续27次即使反馈之后，第28次操作进，计算机让用户等待2分钟，结果半数人在第8.5秒左右就走开或者按下种启键。使用了鼠标指针变成漏斗提示的界面会把用户的等待时间延长到20秒左右，使用动画的鼠标指针漏斗提示界面则会让用户的等待时间超过1分钟，而进度条则可以让用户等待到最后。Peter bickford的调查结果被广泛用到web软件系统的性能需求的响应时间定义中。

　　第三方研究表明，如果网页是逐步加载的，先出现横幅，再出现文字，最后出现图像。在这样的条件下，用户会忍受更长的等待时间，用户会把延迟在39秒内的也标识为“good”，超过56秒的才认为是“poor”的。

80/20原则：又称帕累托效应，比如，某一些系统一天中80%的访问量集中在20%的时间内。

如何根据性能需求进行测试

其实我们上面得到的需求指标仍然是不明确的：

是验证当前硬件和软件配置能否支撑200万vu？

是测试当前的硬件和软件配置最多能支撑多少vu?

是帮助开发寻找性能瓶颈？

根据需求进行性能测试的过程：

　　首先，请你们当前软件和硬件配置下验证能否支撑200万vu。如果可以支撑200万，再增加到300万看是否可以支撑。如果不能达到200万，那么就需要寻找一下是否有性能瓶颈，将主要的性能瓶颈解决后，再看一下是否可以支撑200万，如果可以支撑，输出测试结果。仍然不能，请评估需要添加多少硬件设备。

　　通过上面流程的分析，那么我们对于需求实施过程就非常明确了。

下面看来分析某邮箱系统的需求：

按照 某某 邮箱20000万注册用户，其中日活跃用户数为1.5%的规模计算：

日活跃用户=20000*1.5%=300万

日活跃用户人均每天发6封邮件，用户使用客户端收发邮件比例20%，则：

每天发邮件投递量=300万*6*20%=360万封

如何得到每秒的邮件数？

方式一： 严格的根据2/8原则  ，80%的邮件集中在20%的时间发送。

集中发邮件数：  3600000*80%=28800000封

集中发送的时间：24*20%=4.8小时=17280秒

每秒发送邮件数：2880000/17280=166.7封/秒

方式二，根据 某某邮箱业务模型表，每天忙时集中邮件系数0.15，邮件平均峰值系数2,则：

峰值邮件量=3600000*0.15*2/3600=300封/秒

注：忙时集中系数=忙时业务量/全天业务量

     在两种方式的分析中，方法二得出的结果是方法一的将近一倍，我们不要根据经验理所当然的去分析，要深入的了解系统，我们要对行业指标及计算方式。如果按照第一种方式，性能测试达标了，但系统真正上线后可能远远超出了我们的评估。2008年北京奥运运门票系统就是一个典型的案例。

再来分析系统的登录：

　　去年全年处理“WEB登录”交易约 100 万笔，考虑到 3 年后交易量递增到每年 200万笔。

　　假设每年交易量集中在 8 个月，每个月 20 个工作日，每个工作日 8 小时，试采用 80～20 原理估算系统服务器高峰期“WEB登录”的交易吞吐量应达到怎样的一个处理能力　　

　　200万/8=25万/月

　　25万/20=1.25万/日

　　1.25万*80%/(8*20%*3600)=1.74TPS

----------------------

　　上面的小案例算是抛出的一块砖，需求开发难度要远远大于需求管理，在实际工作中常常需要我们为客户开发这部分性能需求。所以，在追求技术的基础上，请更多的了解分析你的项目及行业指标。　　

 2012-8-24  对部分内容进行的调整。

简单系统架构介绍                                                                              

　　因为每个公司的业务不同，采用的技术，架构也都有很大不同。但不管怎么变动，但基本都在三层架构的基础上扩展与改进。

下面看一个基本的系统架构：

表示层：

　　表示层运行在客户终端上，运行java  applet 程序，提供协议控制和用户界面，与系统用户实现直接交互，通过TCP/HTTP协议与业务层系统通信，向应用层系统发送请求报文，并接收应用层系统返回的回应报文。

业务逻辑层：

　　业务逻辑层作为中间层实现核心业务逻辑服务。

　　应用服务器主要运行中间件系统，中间件系统系统作为一个容器来运行各种应用软件系统。前台发来的请求报文通过中间件传递给应用程序，应用程序在处理的过程中调用数据层的数据服务器，数据服务器将查询的数据返回给应用程序，应用软件处理完成后通过中间件系统返回给客户端。

　　在大型的系统中，可以对应用系统进行拆分，比如拆分成交易服务，查询服务；或者通过负载均衡技术，来分散客户端发来的请求，使其能承受更大的用户访问量。

数据层：

　　数据层运行在数据库主机上，负责整个系统中数据信息的存储。运行数据库服务程序，查询通过JDBC与应用程序进行通信，主要用于存储数据与提供数据查询等服务。

　　数据库集群技术就是对大型系统应用非常广泛的一种解决方案。

大型系统架构介绍                                                                               

　　前面介绍了一般系统的架构，那么一个大型的系统在设计中使用了哪些手段或技术来提高系统的性能呢

操作系统

　　操作系统是硬件与软件之间的桥梁，那么一个稳定的操作系统是系统坚实的基础。在个人操作系统领域，windows 无疑是绝对的霸主，但随着近几年的发展，linux/unix以其不俗的性能表现，超强的稳定性与安全性使其在服务器领域变成重多企业的首选。因为系统服务器由少数技术人员使用，他们更看重系统的性能、稳定性和安全性等方面的表现。

Web服务器

　　Web服务器即中间件服务器，是应用程序的载体（容器），应用程序只有在中间件服务器上才能正常的运行被外界所访问使用。对于window系统来说，IIS是微软配套的web服务器，他们的搭配应该是夫妻是之间的默契；apache 作为开源力量代表，不管在windows还是linux下面都非常得宠。因为linux与apache 都为开源产品且性能优异，应用非常广泛。

　　· 淘宝网（阿里巴巴）: Linux操作系统 + Web 服务器: Apache

　　· 新浪：FreeBSD + Web 服务器：Apache

　　· Yahoo：FreeBSD + Web 服务器：自己的

　　· Google: 部分Linux + Web 服务器：自己的

　　· 百度：Linux + Web 服务器: Apache

　　· 网易：Linux + Web 服务器: Apache

　　· eBay: Windows Server 2003/8 (大量) + Web 服务器：Microsoft IIS

　　· MySpace: Windows Server 2003/8 + Web 服务器：Microsoft IIS

常用的系统架构是:

· Linux + Apache + PHP + MySQL

· Linux + Apache + Java (WebSphere) + Oracle

· Windows Server 2003/2008 + IIS + C#/ASP.NET + 数据库

· Window Server 2003/2008 + tomcat + MySql

提高系统性能的相关技术                                                              

网页HTML 静态化

　　其实大家都知道网页静态化,效率最高,消耗最小的就是纯静态化的 html 页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。

　　但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统 CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理,权限管理,自动抓取等功能,

　　对于一个大型网站来说,拥有一套高效,可管理的CMS 是必不可少的，除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子,文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop 的大杂烩就是使用了这样的策略,网易社区等也是如此同时,html 静态化也是某些缓存策略使用的手段,

　　对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用 html 静态化来实现,比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都 可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以 考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求；

图片服务器分离

　　对Web 服务器来说,不管是 Apache,IIS 还是其他容器,图片是最消耗资源的,于是我们 有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器，这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不 会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如 apache 在配置 ContentType 的时候可以尽量少支持,尽可能少的 LoadModule,保证更高的系统消耗和执行效率；

数据库集群和库表散列 

　　大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

　　在数据库集群方面, 很多数据库都有自己的解决方案, Oracle, Sybase 等都有很好的方案,常用的 MySQL 提供的 Master/Slave 也是类似的方案,您使用了什么样的 DB,就参考相应的解决方案来实施即可。

　　上面提到的数据库集群由于在架构,成本,扩张性方面都会受到所采用 DB 类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案，我们在应用程序中安装 业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略 对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户 ID 进行表散列,这样就能够低成本 的提升系统的性能并且有很好的扩展性，sohu 的论坛就是采用了这样的架构,将论坛的用户,设置,帖 子等信息进行数据库分离,然后对帖子,用户按照板块和 ID 进行散列数据库和表,最终可以在配置文件 中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能；

缓存

　　缓存一词搞技术的都接触过,很多地方用到缓存，网站架构和网站开发中的缓存也是非常重要，这里先 讲述最基本的两种缓存，高级和分布式的缓存在后面讲述， 架构方面的缓存,对 Apache 比较熟悉的人都能知道 Apache 提供了自己的缓存模块,也可以使用外加的 Squid 模块进行缓存,这两种方式均可以有效的提高 Apache 的访问响应能力， 网站程序开发方面的缓存,Linux 上提供的 Memory Cache 是常用的缓存接口,可以在 web 开发中使用, 比如用 Java 开发的时候就可以调用 MemoryCache 对一些数据进行缓存和通讯共享, 一些大型社区使用了 这样的架构， 另外, 在使用 web 语言开发的时候, 各种语言基本都有自己的缓存模块和方法, PHP 有 Pear 的 Cache 模块,Java 就更多了,net 不是很熟悉,相信也肯定有；

镜像

镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异, 比如 ChinaNet 和 EduNet 之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新，在镜像的细节技术方面,这里不阐述太深,有很多专业的现成的解决 架构和产品可选，也有廉价的通过软件实现的思路,比如 Linux 上的 rsync 等工具；

负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法，负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,下面介绍几种常见的负载均衡。

1. 基于DNS的负载均衡--一个域名绑定多个IP

　　DNS负载均衡技术是最早的负载均衡解决方案，它是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，它们也就访问不同地址上的Web 服务器，从而达到负载均衡的目的。

　　这种技术的优点是，实现简单、实施容易、成本低、适用于大多数TCP/IP应用；但是，其缺点也非常明显，首先这种方案不是真正意义上的负载均衡，DNS 服务器将Http请求平均地分配到后台的Web服务器上，而不考虑每个Web服务器当前的负载情况；如果后台的Web服务器的配置和处理能力不同，最慢的 Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用；其次未考虑容错，如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS 请求分配到这台故障服务器上，导致不能响应客户端。最后一点是致命的，有可能造成相当一部分客户不能享受Web服务，并且由于DNS缓存的原因，所造成的后果要持续相当长一段时间(一般DNS的刷新周期约为24小时)。所以在国外最新的建设中心Web站点方案中，已经很少采用这种方案了。

2. 通过硬件四层交换实现负载均衡

　　在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了

3. 通过软件四层交换实现负载均衡

　　软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性。

4. 通过反向代理服务器实现负载均衡

　　反向代理服务器又称为 WEB 加速服务器，它位于 WEB 服务器的前端，充当WEB服务器的内容缓存器,反向代理服务器是针对 WEB 服务器设置的，后台 WEB 服务器对互联网用户是透明的，用户只能看到反向代理服务器的地址，不清楚后台 WEB 服务器是如何组织架构的。当互联网用户请求 WEB 服务时，DNS 将请求的域名解析为反向代理服务器的 IP 地址，这样 URL 请求将被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答、与后台 WEB 服务器交互。利用反向代理服务器减轻了后台 WEB 服务器的负载，提高了访问速度，同时避免了因用户直接与 WEB 服务器通信带来的安全隐患。

-------------------------------------

      这篇文章非常纠结，以目前技术水平来讲这块的东西实属班门弄斧。部分内容从互联网搜集。


各种系统架构图及其简介

1.Spring 架构图

  Spring 是一个开源 框架，是为了解决企业 应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为J2EE 应用程序开发提供集成的框架。Spring 框架的功能可以用在任何J2EE 服务器中，大多数功能也适用于不受管理 的环境。Spring的核心要点是：支持不绑定到特定J2EE 服务的可重用业务和数据访问对象。这样的对象可以在不同J2EE 环境（Web 或EJB ）、独立应用程序、测试 环境之间重用。

组成Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下：

• 核心容器：核心容器提供Spring 框架的基本功能。核心容器的主要组件是BeanFactory ，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC ） 模式将应用程序的配置和依赖性规范与实际的应用程序代码 分开。
• Spring 上下文：Spring 上下文是一个配置文件，向Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如JNDI 、EJB 、电子邮件、国际化、校验和调度功能。
• Spring AOP ： 通过配置管理特性，Spring AOP 模块直接将面向方面的编程 功能集成到了Spring 框架中。所以，可以很容易地使Spring 框架管理的任何对象支持AOP 。Spring AOP 模块为基于Spring 的应用程序中的对象提供了事务管理服务。通过使用Spring AOP ，不用依赖EJB组件，就可以将声明性事务管理集成到应用程序中。
• Spring DAO ：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库 供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写 的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向JDBC 的异常遵从通用的DAO 异常层次结构。
• Spring ORM ：Spring 框架插入了若干个ORM 框架，从而提供了ORM 的对象关系工具，其中包括JDO 、Hibernate 和iBatis SQL Map 。所有这些都遵从Spring 的通用事务和DAO 异常层次结构。

2.ibatis 架构图

ibatis 是一个基于 Java 的持久层框架。 iBATIS 提供的持久层框架包括 SQL Maps 和 Data Access Objects （ DAO ），同时还提供一个利用这个框架开发的 JPetStore 实例。

IBATIS ：最大的优点是可以有效的控制sql 发送的数目，提高数据层的执行效率！它需要程序员自己去写sql 语句，不象hibernate 那样是完全面向对象的，自动化的，ibatis 是半自动化的，通过表和对象的映射以及手工书写的sql 语句，能够实现比hibernate 等更高的查询效率。

Ibatis 只是封装了数据访问层，替我们做了部分的对象关系映射。但代价是必须要写xml 配置文件，相对于Hibernate 还要写很多sql 。Hibernate通过工具直接从数据库模式生成实体类和基本的配置文件，而且大部分情况下不需要我们写sql ，会较大的提升开发效率。但这些也有很多的局限性，尤其是对环境的要求较高（数据库设计，对象设计，团队的协作等）。 个人感觉Ibatis 对项目比较有意义的地方在于它小巧灵活，可扩展，封装了数据访问层（事务，缓存，异常，日志），并提供了DAO 框架支持。

利用Ibatis 我们可以做到代码和sql 的分离，只要sql 能够解决的问题，Ibatis 就能帮我们较容易的解决，同时也使我们的项目对某一框架的依赖性变小（因为Ibatis 是非侵入性的）。这将极大的降低项目风险，减少解决复杂问题的时间，使项目的维护变得简单。

Ibatis 对于应用的修改，调试，扩充和维护将会变得容易自然。修改时，我们主要修改的是代表模型的实体对象，xml 配置文件中的sql ，和/ 或配置文件的ResultMap （很多时候是不需要的）。同时，sql 和代码分离，我们不用在代码的StringBuffer 的append 方法之间寻找需要修改的sql 。配置文件中的sql 便利了我们的调试和对sql 的评审及以后的sql 重用。

3.structs1 架构图

Struts 是Apache 基金会Jakarta 项目组的一个Open Source 项目，它采用MVC 模式，能够很好地帮助java 开发者利用J2EE 开发Web 应用。和其他的java 架构一样，Struts 也是面向对象设计，将MVC 模式" 分离显示逻辑和业务逻辑" 的能力发挥得淋漓尽致。Structs 框架的核心是一个弹性的控制层，基于如Java Servlets ，JavaBeans ，ResourceBundles 与XML 等标准技术 ，以及Jakarta Commons 的一些类库。Struts 有一组相互协作的类（组件）、Serlvet 以及jsp tag lib 组成。基于struts 构架的web 应用程序基本上符合JSP Model2 的设计标准，可以说是一个传统MVC 设计模式的一种变化类型。　　

Struts 有其自己的控制器（Controller ），同时整合了其他的一些技术去实现模型层（Model ）和视图层（View ）。在模型层，Struts 可以很容易的与数据访问技术相结合，如JDBC / EJB ，以及其它第三方类库，如Hibernate / iBATIS ，或者Object Relational Bridge( 对象关系桥) 。在视图层，Struts 能够与JSP ，包括JSTL 与JSF ，以及Velocity 模板，XSLT 与其它表示层技术。

Struts 为每个专业的Web 应用程序做背后的支撑，帮助为你的应用创建一个扩展的开发环境。

  Client browser （客户浏览器）

来自客户浏览器的每个HTTP 请求创建一个事件。Web 容器将用一个HTTP 响应作出响应。

  Controller （控制器）

控制器接收来自浏览器的请求，并决定将这个请求发往何处。就Struts 而言，控制器是以servlet 实现的一个命令设计模式。struts-config.xml 文件配置控制器。

  业务逻辑

业务逻辑更新模型的状态，并帮助控制应用程序的流程。就Struts 而言，这是通过作为实际业务逻辑“ 瘦” 包装的Action 类完成的。

  Model （模型）的状态

模型表示应用程序的状态。业务对象更新应用程序的状态。ActionForm. bean 在会话级或请求级表示模型的状态，而不是在持久级。JSP 文件使用JSP 标记读取来自ActionForm. bean 的信息。

  View （视图）

视图就是一个JSP 文件。其中没有流程逻辑，没有业务逻辑，也没有模型信息-- 只有标记。标记是使Struts 有别于其他框架（如Velocity ）的因素之一

4.structs2 架构图

Struts 2 相对于Struts 1.X ，将实现用户业务逻辑（Action ）同Servlet API 分离开，这种分离机制，是采用了拦截器或者拦截器栈（拦截器链）。拦截器是Struts 2 的核心内容之一。

5.Hibernate 架构图

Hibernate 是一个开放源代码 的对象关系映射框架，它对JDBC 进行了非常轻量级的对象封装，使得Java 程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate 可以应用在任何使用JDBC 的场合，既可以在Java 的客户端程序使用，也可以在Servlet/JSP 的Web 应用中使用，最具革命 意义的是，Hibernate 可以在应用EJB 的J2EE 架构中取代CMP ，完成数据持久化的重任。

　 　Hibernate 的核心接口一共有5 个，分别为:Session 、SessionFactory 、Transaction 、Query 和Configuration 。这5 个核心接口在任何开发中都会用到。通过这些接口，不仅可以对持久化对象进行存取，还能够进行事务控制。下面对这五个核心接口分别加以介绍。

·Session 接口:Session 接口负责执行被持久化对象的CRUD 操作(CRUD 的任务是完成与数据库的交流，包含了很多常见的SQL 语句。) 。但需要注意的是Session 对象是非线程安全的。同时，Hibernate 的session 不同于JSP 应用中的HttpSession 。这里当使用session 这个术语时，其实指的是Hibernate 中的session ，而 以后会将HttpSesion 对象称为用户session 。

·SessionFactory 接口:SessionFactory 接口负责初 始化Hibernate 。它充当数据存储源的代理，并负责创建Session 对象。这里用到了工厂模式。需要注意的是SessionFactory 并不是轻量级的，因为一般情况下，一个项目通常只需要一个SessionFactory 就够，当需要操作多个数据库时，可以为每个数据库指定一个SessionFactory 。

·Configuration 接口:Configuration 接口负责配置并启动Hibernate ，创建SessionFactory 对象。在Hibernate 的启动的过程中，Configuration 类的实例首先定位映射文档位置、读取配置，然后创建SessionFactory 对象。

·Transaction 接口:Transaction 接口负责事务相关的操作。它是可选的，开发人员也可以设计编写自己的底层事务处理代码。

·Query 和Criteria 接口:Query 和Criteria 接口负责执行各种数据库查询。它可以使用HQL 语言或SQL 语句两种表达方式。

6.J2EE 架构图

J2EE 是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。

J2EE 核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE 架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。

7.Oracle 架构图

　　与功能测试相比，性能测试在技术层面具有更大的复杂性。在以往的测试流程中，性能测试只是测试流程的一部分，是系统或验收测试的一个可选项。但随着测试技术的发展。许多公司也单独把性能测试独立出来，建立专门的性能测试小组或团队。那么性能测试在实施的过程中也需要建立独立的流程与规范。

　　虫师提出了自己性能测试流程，与其它书本提出的流程在些小不同。流程的实施没有绝对的对错，适合自身的流程就是正确。

下面看我所提到的流程

性能需求分析

　　性能需求分析是整个性能测试工作开展的基础，如果你连性能的需求都没弄清楚，后面的性能测试工具就无从谈起了。

　　在这一阶段，性能测试人员需要与需求人员（客户）、领导及项目相关的人员进行沟通，同时收集各种项目资料，对系统进行分析，确认测试的意图。当然，还需要客户对性能的态度。

　　测试需求分析阶段的主要任务是确定测试策略和测试范围。策略主要根据软件类型以及用户对系统的性能的需求来定，测试范围则主要分析系统的功能模块进行调研与分析。最终确认明确的需求。

性能测试计划

   确定明确的需求之后，我们要做的工作就是制定性能测试计划。对性能测试过程中所有需要工作制定与规划。

测试计划的大体内容：

　　项目的简单背景描述，本次性能测试的需求与目的，性能需求分析的结果是什么。测试环境的准备，需要什么样的软硬件配置，网络状况登录。测试数据的准备，对于某些性能测试是需要事先准备测试数据的。

　　测试的策略，前面进行需求分析的目的是制定测试策略，也就是设计符合需求的测试场景，需要对系统的哪些业务模块进行测试，如何进行？需要设计哪些场景以及设计这些场景的目的。

最后会明确一下人员配备，比如需要开发、DBA、运维都人员的参与协助，性能测试的时间安排。

测试环境搭建

测试环境搭建，分硬件环境与软件环境，硬件环境主要是向上级审批硬件配备，在某些大型性能测试，可能需要公司购置或租用硬件设备来进行。或者是将来原有设置进行调配与重组，这个时候就需要网络工程师的参与或协助。

软件环境的搭建对于开发人员来说应该毫无压力，比如常见的三大环境，微软的windows + IIS+SQL server 2005+.NET平台、windows/linux+tomcat/weblogic+mysql+java 、linux+ apache+mysql+PHP 等环境。当然身为性能测试人员，不仅也需要会搭建软件平台，更需要对每个平台中的部分有比较深入的了解。因为性能测试的分析并不是死盯着系统应用那一层。中间件、数据库、系统、硬件都有可能成为系统的瓶颈。

性能工具的引入

其实走到这一步进才需要引入性能测试工具，我们在日常的工作中往往是先选定好测试工具然后再分析需求，制定计划进行测试。这样我们在做性能需求分析的时候往往会往往会考虑所选的工具是否能实现，无法实现可能就放弃这个需求或改变这个需求。这样以某一工具为基础点做出的性能测试结果可能是不准确的。

工具的引入分为自行开发与引入市面上的现有工具。市面上的现有工具又分为收费与开源免费，各有各的优缺点。我们要做的是对需求进行分析，从成本，购买成本，开发成本，现有开源工具的二次开发成本，人员学习使用成本以及时间成本等。

在这里再强调一点，不是只有压力测试工具属于性能工具，在性能测试过程中所用到的工具都属于性能工具，如测试数据生成工具，性能监控工具等。

测试的执行

　　测试的执行应该是很大范围的一块内容。也就是我在上一节中性能测试架构所提到的内容。用户行为生成-->压力产生器-->用户代理-->测试调度-->系统监控等。 

　　我们所选择的工具如何来实现我们的需求，这个性能测试工程师对引入的有足够的了解。对协议的了解，可能需要编程的能力等。其实好多新手对性能的学习也是从某一工具的使用开始的。

测试结果的分析

　　这里再重复一次，测试工具只是提供多种不同的数据揭示和呈现方法而已。工具本身并不能帮我们进行性能结果的分析。

　　对于性能测试结果的分析，这个需要性能测试工程师对整个被测环境的各种软硬件都要有深入的了解。当然，在这个过程中我们往往需要各个岗位人员的协助，开发人员、DBA、运维等。致力成为一位资深的性能测试工程师要走路还很长。

软件硬件配置调整与优化

　　说的简单点这个环节属于系统调优阶段。这一项不是一个必须的环节。这个要看你本次性能测试的需求与目的。如果只是为了验证系统的能力的话。在分析完测试结果后就可以出性能测试报告了。

　　对于我们测试人员来说，我们对一个系统进行功能测试的目的是验证系统功能是否是符合需求并可用的，但发现了缺陷之后是需要对缺陷进行跟踪和修复的，并不是把发现的缺陷写在报告里就完事的。当然，功能缺陷与性能缺陷存在着本质的缺陷。如果在性能测试过程中发现不满足需求的缺陷，进行调优是一个不可缺少的过程。

 　　如果要对系统进行调优的话，测试执行、结果分析、系统调优将会形成一个循环持续的过程。直到满足客户的需求为止。

 -----------------------------------------------

对于上面测试流程中所列出的部分，我在后续的博文中会细讲，当然，你也可以对我提出的这个流程进行交流，欢迎留言拍砖，欢迎加性能测试群。

　　在整个系统中，对于不同的软件和硬件，我们对其监控的指标也不一样，就像一个公司中的所有人员，其每个人的职责不同，评判和考核的标准也是不一样的。下面将从系统的各个方面进行分析。

操作系统性能计数器                                                                           

　　操作系统监控器，主要监控操作系统级别上的系统性能表现，这里分析最常见的windows操作系统与Linux操作系统。

window 操作系统的主要性能计数器

Windows操作系统的性能监控：

Window系统下的计数器比较多，主要技术器如下：

Linux/UNIX 操作系统的主要性能计数器

　　Linux系统的命令和UXIN的有些差别，在UNIX系统下的主要计数器监控命令是vmstat、iostat、top、sar、sag(图形方式，需要XServer 支持)；而在linux中，没有isostat命令。另外他们的输出结果也稍有差别。

------------------------------
补充  其实针对不同的场景 我们应采用不同的分析工具和参数  例如 我们要监控web服务器的网络开销  那么我们可以使用httpwatch 和服务端的分析网络协议的软件 计算出整个系统网络负荷，或者我们监控数据库io  我们就要监控系统io 是不是得到负荷  有没有排队的现象等等 

    由于篇幅问题，进程分析，网络分析被遗漏，后面有必要的话会进行补充。

 性能测试的环境准备 

性能测试环境与功能测试环境的区别                                               

　　那么性能测试环境与功能测试环境有什么不同呢？性能测试对测试环境的干净、独立性要求更高，更为严格。对于一个相对较规范的公司，都会建立其独立的研发环境、测试环境、线网环境（最终运行软件的环境）。

（

　　这里多扯一点，系统可以分为C/S架构的系统与B/S架构的系统，C/S架构的系统又可以分为两种，第一种是基本不用与服务器连接的，比如我们用到的java虚拟机JVM，photo shop平面处理软件，我们可以开启软件更新功能，这时软件向服务器发请求，查当前版本是否是服务器端发布的最新版本，然后，提示用例是否需要更新或下载最新版本的软件。当然，我们也可以关闭更新功能或不检测更新。那么这个软件一样可以在电脑上运行。对于这类软件，我的主要测试环境就是用户的电脑。不同硬件配置、不同操作系统下对软件一系列，从安装使用到卸载。除了验证软件与硬件和系统的兼容性能，还需要验证与其它软件是否兼容。

　　第二种类型的C/S软件要时刻与服务器与连接，比如我的在线网游，QQ聊天工具等。从软件的启动就需要与服务器进行连接，对于此类软件，我们测试环境的重点依然是用户电脑，但服务器端必须也有一个相对应的测试环境支撑。

　　对于B/S的系统，我们测试环境的重点就要由用户电脑转为服务器端了，因为系统的所有功能都是由服务器端传递给用户的，所以需要验证服务器传递来的功能是否可用，以及功能的容错能力等。

）

　　再回到测试环境的问题上，对于一些企业为了节约资源，进行功能测试的测试环境，一台服务器可以运行多个系统，通过技术手段可以使系统之间是不会相互影响的（以前公司就是一台服务器上跑多个tomcat）。因为功能测试的重点大于系统对客户端发来的请求是否可以进行正确的处理。

　　那么性能测试为什么对系统的环境要求干净、独立呢？性能测试是要对整个系统运行的软件硬件环境进行测试的，如果某环境下运行多个系统，就很难判断其中的某个环境对资源的占用情况。

性能测试环境包含内容                                                                          

一般web应用系统分为3层架构（在系统架构一章中有介绍）

* 表现层（web服务器）

* 业务逻辑层（应用服务器）

* 数据层（数据库服务器）

性能测试环境包含内容：

硬件：服务器、客户端、交换机等。

软件：数据库、中间件、被测系统、操作系统等。

网络：有线/无线/宽带、网络协议等。

如何保证测试环境与真实生产的一致性                                             

保证性能测试与真实生产环境的一致性，具体从以下三个方面来看：

1、硬件环境，包括服务器环境、与网络环境

　　如服务器的型号以及是否和其它应用程序共享此服务器，是否在集群环境下，是否通过BIGIP进行负载均衡，客户使用的硬件配置情况，使用的交换机型号，网络传输速率。

2、软件环境

版本一致性

　　包括包括操作系统、数据库、中间件的版本，被测系统的版本。

配置一致性

　　系统（操作系统/数据库/中间件/被测试系统）参数的配置一致，这些系统参数的配置有可能对系统造成巨大的影响。所以，除了保证测试环境与真实环境所使用的软件版本一致，也要关注其参数的配置是否一致。

3、使用场景的一致性

基础数据的一致性

　　包括预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别。

　　为了保证每次测试环境的更加一致性，磁盘的使用情况以及磁盘的碎片情况也会或多或少的影响的性能。

使用模式的一致性

　　尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实的模拟用户的使用情况。

性能测试环境的实施策略                                                            

　　上面讲测试环境与生产环境保持一致所需要注意的内容。其实在实际的测试中，我们很难搭建出与生产环境完全一致的一个测试环境，除非我们暂停生产环境用户于进行性能测试，这往往是不可能。一方面某些生产环境是不允许被暂停的，另一方面也为生产环境的安全性考虑。

　　性能测试环境并不像功能测试环境，为了节省资源可以一台服务器上运行多个系统。由于性能测试的特殊性，整个测试环境需要在严格的独立监控下管理，在很多情况下，我们很难申请到足够的且一致的资源（说白了就是老板是否愿意出钱给你买服务器搭建系统）。对于一个并未上线的项目，其生产环境的配置也属于暂定状态，性能测试的目的就是为了确定具体生产环境的硬件配置。这个时候更不可能用过高的配置来搭建性能环境（除非现成的环境放着不用）。

我们一般通过两种策略来搭建性能测试环境（预估方式均有误差）

1、通过建模的方式实现低端硬件对高端硬件的模拟

　　通过配置测试来计算不同配置下的硬件性能和系统处理能力的关系，从而推导出满足系统性能的真实配置情况，这种模拟需要精确的建模，模型的采样点越多，那么得到的结果越精确，从而将在低端配置下的性能指标通过该模型转化为高端配置下的最终预计性能指标。

　　例如：搭建一个低端环境，首先需要对这个环境的CPU和内存进行单独的性能基准测试，同过在不同的配置的性能测试，得到一个基准信息列表，当然，在进行这个性能测试的过程中，我们要确定硬件是系统的瓶颈。如果只用一个CUP，在性能测试过程中，其使用率很低，但得到的性能数据都非常底，这起码说明CUP不是系统的平静，这种情况下就无法得到想要的基准值。

　　如上图，在一颗CPU情况下，运行100个用户且CUP使用率接近饱和（100%）。在增加至两颗CUP的情况下，可以运行190个用户且UPU使用率接近饱和（100%），以此做记录，那么我们就可以推算出运行800个用户需要多少颗CUP。

　　如果你在实际应用中使用的CUP型号及其频率并非完全一样，这个时候可以使用EVEREST工具计算每种CUP的得分，对其性能进行评估。

　　内存也可以使用此方法进行测试推导，这里需要我们多进行试验，对硬件的性能以及对整个项目的结构都要做深入的了解，以便尽量减少误差。

2、通过集群的方式计算

　　对于较大的系统来说，单台服务器的处理能力是有限的，通常都会采用集群的方式来进行负载均衡，完成对海量请求的处理。虽然无法获得整体集群的测试环境，但是可以对集群上的一个节点进行性能测试，得出该节点的处理能力，再计算每增加一个节点的性能损失，同样也可以能过建模的方式得到大型负载均衡情况下的预计性能指标。

　　例如:首先在单台服务器上获得具体的性能指标，每台服务器能够承受500用户并发，平均TPS为60，响应时间为2秒，接着，添加负载均衡策略，再次测试负载策略下的数据损耗。得出数据后添加1台负载均衡服务器，测试在两台服务器下每台服务器的性能指标，以此类推，可以得到下表：

　　随着负载均衡服务器的添加，平均每台服务器的处理能力会逐渐稳定，从而了解在什么情况下需要多少台负载均衡服务器。

　　对于测试环境的搭建，建议生成专门的文档进行管理，并进行配置管理，确保对测试环境做到基线控制。

------------------------------------------

　　这个性能测试系列以理论与性能测试的整体讲解为主，市面上的大部分书籍借着性能测试的表皮在讲性能测试工具loadrunner，那我何不找份loadrunner使用手册来看更好。
总结：我们得测试环境尽量要模拟真实环境 如果硬件达不到 我们可以采用概率论的方法 进行估算，但是软件方面环境必须一致，然后根据我们硬件的配置 进行概率分析后推测，有条件的公司可以进行一次验证。

     你是否觉得我对loadrunner有仇？我之所以将其分开来学，只是希望自己在学习性能测试的时候不要被loadrunner局限了而已。只是觉得在做性能测试时不要带loadrunner的思维，这样更容易把握性能测试的本质。

----------------------------------------------------- 

　　性能测试工具，从广义上讲，在性能测试过程中使用到的所有工具都可以称其为性能测试工具。从狭义上来讲，我们可以把性能测试工具分为服务器端性能测试工具与前段性能测试工具。

　　服务器端性能测试工具也我们测试人员通常所认为的性能测试工具。LoadRunner、JMeter、SilkPerformance、服务器端压力性能工具需要支持产生压力和负载，录制和生成脚本，设置和部署场景，产生并发用户和向系统施加持续的压力。

　　前端性能测试工具应用比较广泛，开发人员，前端开发人员、测试人员都会经常用到。Firebug 、fildder2、Yslow 、前端性能测试工具只需要关于心浏览器等客户端工具对具体需要展现的页面的处理过程。

服务器性能测试工具原理                                                        

　　性能测试工具的主要作用是通过模拟生产环境中的真实业务操作，对被测试系统实行压力负载测试，监视被 测试系统在不同业务、不同压力性能下的性能表现，找出潜在的性能瓶颈进行分析、优化。

　　客户端与服务器相当于两个人，通过信息来进行交流。由于初次见面不好意思直接交流，与是找来了中间传话人，客户端把信息告诉给传话人，由传话人来转达给服务器。那么服务器反馈的信息也由传话人转达给客户端。一般性能测试工具都需要录制或编写客户端行为脚本。

      这样传达人就有了客户端的行为能力，从而假扮客户端来欺骗服务器，与之进行通信。有了客户端行为了传达人可以进行自我复制。从而变出N多个传达人对服务器进通信。---这个传达人的行为和能力也就是性能测试工具的基本特质。（突然觉得性能工具像第三者插足，而且是可以自我复制疯狂变态的第三者，哈哈！）

    　对于目前流行的性能测试工具，他们的基本工作原理都是一致的。在客户端通过多线程或多进程模拟虚拟用户访问，对服务器端施加压力，然后在过程中监控和收集性能数据。

性能测试工具应该具备什么的特质呢？

1、工具本身占用系统资源少，可扩展性好，可用性强。    

2、能模拟真实业务事务操作，在并发时能真正产生业务压力。（这一点是核心）

3、对压力测试结果能很好地进行性能分析，快速找出被测试系统的瓶颈。

4、测试脚本的重复性强。

服务器性能测试工具的架构                                                             

用户行为生成部分

     我为什么说的这么朦胧，对于熟悉loadrunner的朋友，我说成虚拟用户脚本生成器，你更容易理解，这个脚本，我们可以录制，也可以手工编写。你不要以为这是生成用户行为的唯一方式。因为在JMeter成中是添加各种组件，通过对组件的配置来完成用户行为的，当然也可以通过录制。而在相对简陋的性能测试工具curl_loader（linux环境下的运行的），他是通过编写配置文件的形式来描述用户形为的。

     我前面也有提了，虽然性能测试工具由不同的形式来描述，但他们的原理是一样的，都是通过Proxy方式来实现，具体来说，Proxy作为客户端和服务器之间的中间人，接收客户端的数据包。

压力产生器

　　压力产生器用于根据脚本内容产生实际的负载，在性能测试工具中，压力产生器扮演着“产生负载”的角色。也就根用户的设置，进行自我复制来生成多个客户端向服务器发送请求。对于工具来说，每复制出来的一份就是一个进程或线程，进程和线程的运行是要占用系统资源的。所以，对一台压力测试机来说能运行的虚拟用户数也是有限的。根基测试机的配置而定。那么这个时候就要通过多台测试机合作，来模拟更多的虚拟用户向服务器发请求。

　　那么，对于性能测试来说，很重要的一点就是产生“并发”的请求，不然就不会对服务器产生压力。那多台机子如何产生“步调一致”的虚拟用户呢？使用“用户代理”

用户代理

　　用户代理是运行在负载机上的进程，该进程与产生负载压力的进程或线程协作，接收调度系统的命令，调度产生负载压力的进程或线程，从这个意义上看，用户代理也是压力产生器的一部分。

调度能力

　　我们在做复杂的性能测试时，常常会设计各种场景，不同的虚拟用户数，不同事务的用户比例，运行时间，设置同步点等，这个时候也需要我们的测试工具有压力调度能力。从而才能更真实的模拟我们所设计的运行场景。

监控系统

　　监控系统是性能测试工具直接与用户进行交互的主要部分，监控系统，主要用户在压力测试过程中对各种软硬件进行监控，如对数据库、应用服务器，服务器的主要性能表现情况进行监控。用于判断系统当前处于什么状态。

　　当然，监控系统不是性能工具必须的部分，可以通过软硬件系统自身的监控工具或者第三方监控工具进行监控。但是否有强大的性能计数器监控系统是衡量性能测试工具是否强大的指标之一。

压力结果分析

　　压力结果分析工具可以用来辅助进行测试结果的分析，性能测试工具一般都能将监控系统获取的性能技术数器值生成曲线图，折线图等各种图表。通过展现性能测试过程中的各种参数指标，来供测试人员进行分析。

　　但这里需要强调的是，压力结果分析工具本身不能代替分析者进行性能结果分析，而只是提供多种不同的数据揭示和呈现方法而已。对于这些数据进行分析必然要依靠测试工程师对系统性能分析的知识和经验。

------------------------------------------------------- 

　　对上面介绍的性能测试工具架构的组成部分，不是第一个性能测试工具都具备，而所具备的强大程度也不相同。比如，有些性能测试工具不具备用户代理能，有些监控系统能监控的资源很有限或简陋，有些结果分析数据的呈现不够详尽等。

　一：性能测试工具模型

　　广义地说，性能测试工具是指性能测试过程中使用到所有工具，但是我们习惯上把“性能测试工具”定位于LoadRunner、SilkPerformer一类的工具。

　　关于性能测试的几个误区：

　　1、认为性能测试就是使用性能测试工具进行测试。

　　性能测试工具只能帮助你实施性能测试，并不能帮助你完成性能测试的需求、设计和分析。

　　2、认为性能测试工具可以完成性能测试结果分析工作。

　　性能测试工具只是能够根据你的要求以各种方式提供报表，这些报表可以被您用来分析系统性能状况。

　　3、不清楚性能测试工具的录制/回放与功能测试工具的录制/回放的区别。

　　功能测试工具的录制/回放一般是针对GUI的操作录制，脚本中记录的是用户对控件的操作，例如按下了“确认”按钮或是在“姓名文本框”中输入了ABCD等内容，这时因为功能测试工具主要是通过操作和数据来验证功能的正确性，评价的主要标准是GUI的正确性（界面内容的正确性）。而性能测试工具录制的是服务端和应用之间的通信数据，而不是应用的GUI操作。^_^^_^理解了这一点，就不难明白为什么在进行性能测试脚本录制的时候，需要首先选择录制的协议了。

　　4、不清楚何时选择何种协议。

　　选择何种协议取决于应用和客户端之间的通信协议。

　　二：性能测试工具架构

　　1、虚拟用户脚本产生器（Virtual User Generator）：通过一个Proxy作为客户端和服务器之间的中间人。

　　2、压力产生器(Player)：压力器扮演着“产生负载”的角色。

　　3、用户代理(Agent)：运行在负载机(LoadMachine)上的进程，该进程于产生负载压力的进程或是线程写作完成“产生负载”的功能。如一台PC可以顺利运行200个左右的VU，但对需要1000个VU的情况显然很难指望一台PC，这时就需要通过多台及其进行协作，“用户代理“就帮助产生”步调一致“的VU。

　　4、压力调度和监控系统(Conductor)：直接与用户交互的主要内容，压力调度可以根据用户的场景要求，设置各种不同脚本的VU数量，设置同步点等，而监控系统则可以对各种数据库，应用服务器、服务器的主要性能计数器进行监控。

　　5、压力结果分析工具(Analysis)：用来辅助进行测试结果的分析。

　　三：性能测试脚本录制时的协议类型

　　^_^^_^不要想当然地根据开发语言来决定协议的选取，这样子极有可能导致录制后的脚本不能回放成功。

　　几点说明的内容：

　　1、使用Socket协议可以对任何类型的应用通信进行录制，但这种录制生成的脚本很可能没有任何意义。

　　2、在对应用间的通信进行录制生成脚本后，对脚本进行回放，有时会出现回放无法继续的情况（停留在某个步骤无法进行下去），此时应该考虑是否使用了合适的协议。

——————————————协议选择参考方案——————————————————————

　　1、Web应用：应用特点：采用J2EE或是dontNet结构，HTTP/HTTPS协议。

　　2、C/S应用：

　　a、客户端程序以ADO、OLEDB方式连接后台数据库，选择后台数据库类型选择相应的协议。

　　b、客户端程序以ODBC方式连接后台数据库，ODBC协议。

　　c、其他协议，根据具体协议类型进行分析。

　　3、组件：a、COM/DCOMcom/dcom协议。

　　b、EJB，EJB协议。

　　4、服务：

　　a、WebService，WebService协议。

　　b、Mail服务器，SMTP/POP3协议。

　　c、FTP服务器，FTP协议。

　　5、应用服务器：

　　a、OracleApplicationServer,OracleApplicationServer协议。

　　b、SAP，SAP协议。

　　c、Tuexdo,Tuexdo协议。

　　四：性能测试工具的选择与评估

　　这个问题通常会有两个层面的意义：第一，创建还是购买？第二，如果购买，如何选择一种商业工具？

　　1、创建还是购买？

　　总而言之，”购买“的方式可以以较低的总体成本快速获得可用的软件，但如果被测试对象本身有一定的特殊需求，最好使用”创建“的方式构建适合的测试工具。

　　2、测试工具的评估和选择过程。

　　（1）列出需要的工具功能列表

　　（2）工具比较

　　（3）成本分析

　　如果考虑到web应用本身的特性，响应时间的构成应该会更加复杂。 

　　Web应用的基础是超文本传输协议（HTTP）和超文本标记语言（HTML），HTTP协议本身是一种面向非连接的协议，HTML语言则是一种用于制作超文本文档资料的简单标记语言。

　　对于一个页面而言，“请求”和“返回数据”都可能是多次发生的。这个我在《在做性能测试之前需要知道什么》一文中举了一个简单的例子来讲解。由于HTTP对浏览器下载资源并发请求数量、Cache等方面都进行定义和限制，以及浏览器对于HTML的处理过程。完全可以说，用户所以感受的响应时间中的相当大的一部分并不完全取决于应用的后台处理所需要的时间，而取决于web应用的前端。在yahoo中，到少50个团队通过纯粹的前端性能相关的技巧，将最终用户的响应时间减少了25%以上。

　　HTTP是一个属于应用层的面向对象的协议，用于传送WWW方式的数据，采用请求\响应模型，客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本，以及包含请求修饰符、客户信息和内容的类似于HTML的消息结构。服务器以一个状态行作为响应，响应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息，实体元信息以及可能的实体内容。

　　 HTML是一种用于制作超文本文档资料的简单标记语言，用HTML编写的超文本文档能够独立于各种操作系统平台。从诞生开始，HTML语言就一直被用于描述web页面格式设计，使用HTML语言描述的文件需要通过WWW浏览器显示效果。

用于查看前端性能工具太多的。

　　嵌入浏览器的有 yslow 、page speed、httpwatch

　　独立界面的有 fiddler2、charles 、

页面性能测试之一 ： http://www.cnblogs.com/fnng/archive/2011/09/19/2181894.html 

 http://www.cnblogs.com/fnng/archive/2011/09/24/2186708.html

下面用两种方式来对比较两种测试响应时间的差别

　　Apache  benchmark 简称ab ，是非常有名又小巧的压力测试工具。

　　下载安装apache web server 安装或解压之后，在bin\目录下有个ab执行文件。

　　打开运行--cmd 打开命令提示符，定位到bin\目录下。

基本用法：

ab  -c  [并发用户数]  -n  [发送请求数]   [被测试页面的URL]

设置一个用户一个请求，对百度首页加压：

http://www.baidu.com/

从上表中我们可以看到请求的总字节数为8024字节；响应时间为0.173 秒，也就是下面显示的173.010毫秒。 

 ---------------------哥伦布哥----------------------------------------------------------------

Firebug非常有名的debug工具，firefox浏览器最得意的集成工具。

在firefox浏览菜单栏“工具”---添加组件---搜索firebug下载安装重启浏览器。

同样对百度首页的访问：

http://www.baidu.com/

从上面图中看到请求的大小为10KB；响应时间1.4秒。清楚的发现这数据可以远远大于ab工具所得到的数据。仔细观察发现，firebug给出的数据，访问 http://www.baidu.com/ 网址时，客户端（浏览器）和应用之间的数据交互并非1次，而是5次。

　　我们再分析其中的一个请求，firefox给出的的图形中，有红色和蓝色两种颜色的线条。蓝色表示到此刻发生了DOMContentLoaded事件。红色线条表示onload事件被触发。DOMContentLoaded事件W3C推荐的标准事件，它发生在页面的DOM树建成时，而onload则发生在页面所有的资源（图片文件、CSS文件、js文件等）都被下载完成后。

　　从上图的右下角，我们会得到两个响应时间，1.41秒是onload事件被触发的时间，前面的1.4秒则是页面的所有请求都返回所需要的总时间。那么哪个时间才是用户感受到的响应时间呢？准确的说，两个都不是。用户的感受是个不确定的状态，取决于页面本身的类型以及呈现手段。如果某页面仅为用户提供阅读信息，一旦页面上开始出现可供阅读的内容，用户就开始阅读了。那么，用户认为响应时间就是发出请求到页面上出现可阅读信息。如果页面存在大量的交互内容，需要用户填写或在页面上进行拖拽等操作，在这种情况下，只有当页面的所有元素都被下正确的呈现出来，所有的js文件都已经执行完成后，用户才会感受到这个页面已经就绪。

　　Web前端性能的研究并不是为了准确地得到一个响应时间数据，实际上，根据friebug图表的结果，web性能一部分取决于web服务器和应用服务器（建立连接，下载连接），别一部分取决于浏览器的实现机制、web页面上的js的执行等。取决于web服务器和应用服务器的响应时间与服务器的负载、压力等相关；而取决于浏览器实现机制与js文件执行所需要的时间则几乎与服务器端的负载和压力无关。那么web端的响应时间也是总响应时间的一部分，那么有必要web端的性能进行了解。

　　那么前端性能这么见效，为什么还要去做后端性能测试呢？因为他们关注点不同，前端性能关注单个用户的感受。后端性能关注是更多用户访问系统时，服务器能更稳定、更快的处理用户发来的请求。一个强大的后台是前台的基础。

简介

结构

用户的经验

重要性

维护和管理

2操作系统编辑

一个长时间的处理完成时 应给予完成警告信息　

　从用户角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮，发出一条指令或在web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。

响应时间过程分析

　　我们需要对这个过程进行分解，才能得到你真正想要的响应时间。我把整个过程分三个部分，呈现时间，数据传输时间和系统处理时间。

呈现时间

　　其实主要说的浏览器对接收到数据的一个处理展示的过程。几年前大家都在用IE，如果页面显示比较慢，我们肯定不会怪罪IE，只会怪罪电信运营商的网速或被访问的系统（其实，大多情况我们不会考虑是被访问系统的问题）。现在chrome来了，我们会发现同一台电脑同一个网站，通过chrome去访问，页面的呈现速度会比IE略快。这是各种评测及大众用户的整体感受。当然，我个人感觉，opera浏览器的呈现速度最快，但它的显示效果一直不太好。

　　当然，我说这个呈现时间总不能全怪罪与浏览器的身上吧！当然还和承载它的操作系统有关，以及电脑硬件（比如cpu 内存）。假如你有超快的浏览器，如果是一台极其垃圾的电脑，我想你多打开两个网页就有可能使电脑卡掉。

数据传输时间

　　千万不要忽视数据传输时间。如果你要寄信给你一个远方的朋友，你想是什么影响你将信息传递给远方的朋友？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。（ps, 我10天前在china-pub订购的一本书现在还没到货！XXX）

　　拿我们系统的数据传输过程来说，我们发送一个请求需要时间，系统处理完后返回给我们也需要时间。初学性能测试工具的同学喜欢拿工具去测试互联网上的一些系统，甚至不懂性能的同学认为可以用性能测试工具将互联网上的一些网站压崩溃。貌似这一招比任何黑客攻击厉害多去。

　　那么，我觉得这些同学应该补补网络知识了，你的带宽是多少？互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。有没有考虑网络延迟？就算你的并发请求都能成功的发出，但到目的地的时候，已经不能叫并发了。

　　这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。当然，也有特殊的性能测试需要在互联网中时行。它们重点不是求用户的最大的并发量。

系统处理时间

系统得到请求后对请求进行处理并将结果返回。那我进行性能测试主要就是验证系统的处理时间，因为前面的呈现时间和数据传输时间都我们不可控制的，用户使用的电脑及浏览器千差万别，用户的网络状况千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短暂。

如果我们对系统的的处理进行分析和讲解的话，它会是一个非常庞大与复杂的过程。语言、语言框架、中间件，数据库、系统架构以及服务器系统。所以，想成为一个优秀的性能测试工程师我们的路还很长。

实际性的能测试

      听了上面的分析，貌似每个过程都挺“浪费”时间，那么我们如何只测试系统的处理时间呢？

　　其实现在的测试工具都屏蔽呈现过程，只是模拟多用户并发请求，计算用户得到响应的时间，页不会将服务器的每个响应都向客户端呈现。

　　对于数据传输的问题，这也是我要强调的性能测试要在局域网中进行，在局域网中一般不会受到数据带宽的限制。所以，可以对数据的传输时间忽略不计。

 响应时间的定义：

响应时间

　　指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。

系统响应时间

　　应用系统从发出请求开始到客户端接收到响应所消耗的时间。需要注明的是，这样的定义完全是个人喜好。你可以提异议。

我们来看两种情况：

　　我要访问百度首页，发出了一个请求，百度开始给我返回页面数据，当搜索框与搜索按钮都已经返回到页面上了，但那个图标还在发送中。我不认为这个响应是完整的。必须把页面上的所有信息都返回给我才是完整的，我要的也是所有结果返回给我的时间。这种情况更符合“相应时间”的定义

     某系统有一个信息查询功能，当我输入某条件查询时，可能要查询几百万条数据，如果数据库，要查询所有的数据并把所有的数据全部完整的返回给我。可能服务器要查询很久，而我的电脑全部接收这些数据也可能只直接挂掉。那么服务器可能只查询100条数据并把数据返回给我，当我点击“下一页”时，服务器再次查询并将第二页的数据返回给我。这种情况更符合“系统响应时间”的定义。

　　关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。

合理的响应时间

　　在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。

　　也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。

　　这里我们还要考虑一个使用频率的概念。

　　我最早安装windows系统可能要1个小时，我们为什么觉得这很正常，因为我们要很久才装一次系统，如果系统使用得当，可能一个系统用几年不用重装，假如，我们在系统上装个任何小软件都要这么长时间，那我们一定是无法忍受的。对于软件控来说，他们会时常安装各种新鲜有趣的软件进行使用。

对于一个税务报账系统，该系统的用户每月使用一次，一次花费3小时进行数据的录入，

当用户单击“提交”按钮后，即使系统在10分钟后才给出“处理成功”的消息，我们也觉得是可以接受的。

    因此，在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定。

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。

　　提示，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力是10个水龙头的强？所以，我们要加单位时间，看谁1秒钟的出水量大。这就是吞吐率。
系统吞吐量：系统吞吐量是指系统在单位时间内所处理的信息量，它以每小时或每天所处理的进程数来度量。

系统吞吐量是指系统在单位时间内所处理的信息量，它以每小时或每天所处理的进程数来度量。

　　影响吞吐量因素：

　　1、存储设备的存取速度，即从存储器读出数据或数据写入存储器所需时间；

　　2、CPU性能：1）时钟频率；2）每条指令所花的时钟周期数（即CPI）；3）指令条数；

　　3、系统结构，如并行处理结构可增大吞吐量。

　　大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作，对系统造成压力，来验证系统的性能（不太标准的解释）。好多人也简单的把性能测试当成并发测试。那么这个“多用户”和“同时”两个因素缺一不可。只多用户不同时，很难对系统构成压力；没有多个用户，同时的概念也就自然不存在了

并发的两种情况

　　一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。

　　另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。

从服务器的角度来看并发

　　前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

　　如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所谓的服务器所承受的最大并发访问数。

真正意义上的并发不存在

　　上面试谈了这么多并发，现在又说真正意义上的并发不存在。何解？学操作系统原理的同学都知道，CPU在一个时间点上只能干一件事儿。为什么我们可以边看电影，边打字，边语音。因为CPU很快很快，他可以处理一下电影，再处理一下打字，再处理一下语音。因为它很快，所以，它可以在多个程序之间快速瞬间的切换，给你造成的假象就是它在同时做这些事情。（现在的双核、四核的CPU另说）

　　那么我们的系统在接到用户的请求后也要调用CPU来完成某些处理，然后返回给用户。那么我们对系统有做并发测试是测什么呢？举个简单的例子。假如有一位神医，他的看病速度非常快，假设他的看病速度是不变的；然后有一群接待人员来接待看病的客人，有成千上万的病人来看病，接待人员要想各种办法来做好接待工作，使病人更快的看到病。比如，可以事先咨询病人得的什么病，然后将病人进行分类，比如可以扩大接待室，让更多的病人可以进到医院来看病等。

　　神医就是我们的CPU，接待人员就是我们的系统，病人就用户，我们做性能测试的目的就是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人，医院的看病速度与服务很好。一下子来十万个病人各种问题就出来了。接待人员的服务态度下降，多余的人员跟本进不到医院去，医院的洗手间不够用，造成病人无法上厕所而离开，这些都属于系统问题。所以，我们一般测试的目的是看医院的接待能力。

系统用户数与同时在线人数

　　在实际的性能测试中，经常接触到与并发用户相关的概念还有“系统用户数”与“同时在线人数”下面通过一个实例来描述他们之间的差别。

　　假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这就是说有20万用户可以使用这个网站的所有功能，20万就是这个网站的“系统用户数”，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”

　　那么系统的并发用户数是多少呢?2万么？NO!这2万只表示在系统最高峰时有这么多用户登录了网站，并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关，在这2万用户中考察某一个时间点对用户发出请求数，可以会大大缩水。那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过服务器日志的分析得到。

求并发用户数公式

在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务的角度关注应该设置多少个并发数比较合理。

下面找一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。

　　　　C=1000/30*5=166.7

C表示平均并发用户数，那么对这个签到系统每分钟的平均在线用户数为166

当然，在性能测试上，任何公式都不是严谨的，最重要的是对系统做出有效正确的分析。

 --------------------------

     估算并发用户并发数公式：

先说说性能测试（狭义）的定义

　　性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。

特点：

1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。

通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。

特点：

1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。

打个比方 例如 每次吃饭只吃一碗米饭，结果为了检测你最多能吃多，那就不停地让你吃，直到你实在吃不下去，哈哈 崩溃了吧~

压力测试

压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误

特点：

1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。

打个比方，CPU在满负荷的状态下 你在去打开几个应用 看系统会不会崩溃 等等~

并发测试 

并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。

特点：

1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。

打个比方  例如 一个饭堂最多能容纳100人吃饭，结果中午去了 200个在同一时刻去吃饭，结果100只能等着别人吃完饭 所以最大并发数为100

配置测试

配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。

特点：

1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。

打个比方  例如 我们玩一个款大型网络3D游戏 你拿很烂的双核1G机器玩  赶紧很卡   但是你拿4核4g的机器玩 我靠 怎么这么流程 这就叫配置测试

可靠性测试

在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

特点：

1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）
3、测试过程中需要关注系统的运行状况。

打个比方 例如 老板说这一个月你都要每天加班到晚上10点，OK 如果你这一个月能扛下来的话，那通过测试，结果你干了2星期 身体垮了 测试失败们哈哈 是不是有点变态

一个实际的例子

为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。

这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^

l         系统总容量达到日委托6000万笔，成交9000万笔

l         系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔

l         实际股东帐号数3000万

这个例子中已经包括几个明确的需求：

l         最佳并发用户数需求：每秒7300笔

l         最大并发用户数需求：峰值处理能力达到每秒10000笔

l         基础数据容量：实际股东帐号数3000万

l         业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型

如何获得有效的性能需求

上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：

1.       客户方提出

这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。

2.       根据历史数据来分析

根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。

3.       参考历史项目的数据

如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。

4.       参考其他同行类似项目的数据

如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。

5.       参考其他类似行业应用的数据

如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。

6.       参考新闻或其他资料中的数据

最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。