TPS与HPS

　　TPS （Transactions Per Second）是估算应用系统性能的重要依据。其意义是应用系统每秒钟处理完成的交易数量，尤其是交易类系统。一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。依据经验，应用系统的处理能力一般要求在10-100左右。不同应用系统的TPS有着十分大的差别，一般需要通过性能测试进行准确估算。当系统没有达到性能瓶颈时，TPS随着负载的增加呈近似线性增长，当接近性能瓶颈时出现拐点；如果系统健壮性较好，在到达性能瓶颈后，TPS基本保持水平，不会再随着负载的增加而有显著增长；而如果系统存在比较严重的性能问题，当到达性能瓶颈后，TPS会出现明显的下降趋势。HPS：（Hits per Second）每秒点击次数，是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。

　　TPS可以有多种衡量单位，在进行性能测试的业务模型分析时使用，例如：

　　（1）在税务系统中，可以用“系统每个月要处理10万用户的业务操作”，这里的TPS用企业数/月来衡量；（2）在税务系统中，也可以用“系统在第七天的8个小时内要处理4万用户的业务操作”，这里的TPS用企业数/天来衡量；（3）在税务系统中，也可以用“系统在第七天的10点到11点之间要处理1.2万用户的3种缴税交易操作，即3.6万次缴税交易操作”，这里的TPS用交易数/小时来衡量；（4）在税务系统中，也可以用“系统在第七天的10点到11点之间要处理1.2万用户的3种缴税交易操作，即3.6万次缴税交易操作，每次缴税交易要从客户端向服务器发送平均10次HTTP请求，即36万次HTTP请求操作”，这里的TPS用请求数/小时来衡量。

　　HPS是用来衡量很多用户使用客户端进行操作，向服务器发送请求的效率。我们认为HPS表现的是最终用户的整体行为，是衡量在线负载程度的一个指标。而TPS表现的是服务器端的程序行为，是衡量服务器处理能力高低的一个主要指标。

　　例如：HPS＝“点击次数/秒”；TPS＝“处理事务数/秒”，HPS与TPS没有绝对的关系。

　　性能测试实现的准确性

　　在进行了正确的性能测试分析后，获得了正确的性能测试需求，从而使用性能测试工具开发相应的性能测试脚本、开发相应的性能测试场景、在性能测试脚本中利用性能测试数据、在性能测试脚本中设置相应的思考时间、在性能测试场景中设置运行的参数等，以期能利用自动化的性能测试工具模拟现实中大量用户同时访问被测系统的情形。即，如果性能测试工具操作不当，将会导致无法准确的实现“模拟实际情况”的目标。例如，某些性能测试工程师在使用性能测试工具时不懂得利用“检查点”这个功能，从而无法发现在性能测试执行过程中大量虚拟用户甚至没有登陆到系统中的严重问题，仍然认为性能测试执行效果良好，被测系统性能没有问题。

　　Web服务器和APP服务器

　　通俗的讲，Web服务器传送（serves）页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用（call）的方法（methods）。确切一点，你可以说：Web服务器专门处理HTTP请求（request），但是应用程序服务器是通过很多协议来为应用程序提供（serves）商业逻辑（business logic）。Web服务器（Web Server）Web服务器可以解析（handles）HTTP协议。当Web服务器接收到一个HTTP请求（request），会返回一个HTTP响应（response），例如送回一个HTML页面。为了处理一个请求（request），Web服务器可以响应（response）一个静态页面或图片，进行页面跳转（redirect），或者把动态响应（dynamic response）的产生委托（delegate）给一些其它的程序例如CGI脚本，JSP（JavaServer Pages）脚本，servlets，ASP（Active Server Pages）脚本，服务器端（server-side）JavaScript，或者一些其它的服务器端（server-side）技术。无论它们（译者注：脚本）的目的如何，这些服务器端（server-side）的程序通常产生一个HTML的响应（response）来让浏览器可以浏览。要知道，Web服务器的代理模型（delegation model）非常简单。当一个请求（request）被送到Web服务器里来时，它只单纯的把请求（request）传递给可以很好的处理请求（request）的程序（译者注：服务器端脚本）。Web服务器仅仅提供一个可以执行服务器端（server-side）程序和返回（程序所产生的）响应（response）的环境，而不会超出职能范围。服务器端（server-side）程序通常具有事务处理（transaction processing），数据库连接（database connectivity）和消息（messaging）等功能。虽然Web服务器不支持事务处理或数据库连接池，但它可以配置（employ）各种策略（strategies）来实现容错性（fault tolerance）和可扩展性（scalability），例如负载平衡（load balancing），缓冲（caching）。集群特征（clustering—features）经常被误认为仅仅是应用程序服务器专有的特征。

　　应用程序服务器（The Application Server）根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括HTTP，把商业逻辑暴露给（expose）客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法（或过程语言中的一个函数）一样。应用程序服务器的客户端（包含有图形用户界面（GUI）的）可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭（traveling）的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑（program logic）。 正是由于这种逻辑取得了（takes）数据和方法调用（calls）的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。在大多数情形下，应用程序服务器是通过组件（component）的应用程序接口（API）把商业逻辑暴露（expose）（给客户端应用程序）的，例如基于J2EE（Java 2 Platform， Enterprise Edition）应用程序服务器的EJB（Enterprise JavaBean）组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作（gate-keeping duties）包括安全（security），事务处理（transaction processing），资源池（resource pooling）， 和消息（messaging）。就象Web服务器一样，应用程序服务器配置了多种可扩展（scalability）和容错（fault tolerance）技术。 例如，设想一个在线商店（网站）提供实时定价（real-time pricing）和有效性（availability）信息。这个站点（site）很可能会提供一个表单（form）让你来选择产品。当你提交查询（query）后，网站会进行查找（lookup）并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。