测量Web服务器的性能
测量Wd服务器的性能是一件令人畏惧的工怍，笔者会在这里指出重点需要考虑的问 题，并指引读者参阅更详细的资源。有太多与Web服务器性能有关的变量，而无法在这里一一说明。大多数的测最策略会包括“客户端”程序，以假装成实际上可同歩送出大量请求的浏览器，然后测量响应时间。
在测量Web服务器的性能之前，需要选择测试性能的方法及确实要测试的内容。例如， 负载测试客户端与服务器软件包是在同一台机器吗？笔者强烈反对这柞做。让客户端与 服务器运行在间一台机器上，一定会改变并使测试结果不稳定。在测试服务器端机器是否正在执行其他的程序？客户端与服务器是以千兆位（gigabit)的以太网络，还是 lOObaseT, lObaseT相连呢？根据以往经验，如果负载测试客户端机器通过低于千兆以太网速度的网络信道链接到服务器端，那么网络链接会降低测试速度，从而改变测试结果。
是屡次请求相同的网页，混合多种不同的并发请求，还是从庞大的网页清单中随机挑选呢？这能影响服务器及多线程缓存性能。在这里所做的事情要取决于所仿真的客户端负 载而定。如果仿真如操作人员这样的用户，它们可能会请求各种网页而不是重复请求一个网页。如果仿真编程过的HTTP客户端，它们会重复请求相同的网页，因此您的测试 客户端大概要完成相同的事情。定制客户端流量，然后让负载测试客户端完成客户端实际要完成的事情。
测试客户端应按常规方式还是应该以突发（burst)方式发送请求呢？按基准调校来说，当您欲知道多快的服务器能完成请求时，应使测试客户端在请求之间不经暂停、快速连 续地发送请求。运行的服务器是最终配置吗？根据基准调校的需要，应关闭所有调试工作，且还可能要关闭一些日志HTTP客户端请求了图像还是仅请求了嵌入于其中的 HTML页？这要依您要仿真的操作员产生的Web流量而定。笔者希望您看到这一点：可 以运行多种不同的性能测试，且每种测试都将产生不同（可能是有趣的）结果。
测试负载的工具
大多数测量Web负载的工具，其主要的做法是按一定（大量）次数，请求Web服务器一种或多种资源，并计算出实际所占用的时间或每秒钟可以访问该网页的次数。市面上已有许多测址Web负载的工具，请参阅http://www.softwareqatest.com/qatweb1.html#LOAD 査看列表。一些比较著名的测量工具包括Apache Benchmark (ab,内含在Apache httpd Web服务器的发行版中，网址为http://httpd.apache.org)、Siege (谓参见http://www.joedog.org/JoeDog/Siege)以及 Apache Jakarta 的 JMeter（请参见http://jakarta.apache.org/jmeter）。
在上面的三种负载测试工具中，JMeter是最有特色的，它纯粹是用多平台Java实现的， 不仅提供了用于设置和加载图形的优良图形化用户界面，而且在Web测试及生成报告上非常有特色。非常灵活，并能在纯文本模式下使用，还拥有显示如何配置及怎样使用的 详细文档。根据笔者经验，JMetcr提供了定制测试结果的最具报表特性的选项，是最能 适应不同操作系统的工具，而且支持大部分功能。但是，出于某种原因，JMeter不能像ab和Siege所做的那样，每秒钟请求并完成那么多次HTTP请求如果您不是为了不设法 找出您的Tomcat能每秒响应多少次请求，JMeter就是最好不过的选择了，因为它基本实现了您所要实现的所有功能。但是，如果您要确定服务器每秒最多能成功处理多少请 求，那么笔者建议您使用ab或siege。
如果您正在寻找基于命令行的基准调校工具，那么采用就很不错。它也仅是一个基准调校工具，所以一般不会把它用于递归测试。虽然它不具备图形化用户界面（除了在基 准调校工具上一次提供一个URL之外，您无法一次给基准调校工具提供多干-个URL的 列表），但它能很好地提供精确钱减的详细结果。在大多数非Windows操作系统h，ab 是与Apache—起预先安装的，或者用包含d々的官方Apache 包进行安装，从而 使安装成为所有Web负载测试工具中最易安装的事情。
Siege是另一个很好的命令行（不是GUI）Web负载测试工具。在大部分操作系统中，它不是提前安装的，但它的编译和安装指令都很直接而且尽可能简单，况且Siege的代码还是髙度可适应于多种操作系统的C源码。Siege支持多种不同的认证特性，并可执行基准测试、递归测试，还支持“Internet”模式测试（即尽可能仿真在Internet上Web应用程序要进行交互的众多实际用户所产生的负载）。其他不具特色的工具似乎都不太支持 Web应用程序认证方式，但它们支抟发送cookies的功能，不过某些工具可能不支持接收 cookies的功能。另外，虽然Tomcat支持几种不同的认证方法（基本、摘要、表格式和客户端认证），但这些不具特色的工具则只支持HTTP基本认证。基于表格的认证方式可以用能提交表格的任意测试工具进行测试这要依这样的测试工具是否支持从登录表单提交POST HTTP请求而定（JMeter、和siege都支持以这样的方式发送POST请求）， 只有部分工具支持这样处理。尽景仿真实际在线用户认证是性能测试的重要环节，因为 认证本身通常是髙负荷的操作，而且会改变Web站点的性能特性。依实际产品中使用的 认证方法而定，您可能需要寻找支持这种认证方法的不同工具。
ab: Apache基准调校工具
工具接受单一的URL,然后重复地按照您指定的多独立线程的方式加载它，并使用各 种不同的命令行参数来控制访问的次数、最大的并发访问数等。其中一项不错的功能足 可以定期地打印进度报告，而另一项优点则是可以输出十分详细彻底的报告。
在基准调校测试的时候，测试客户端请求HTTP的数量域少， 测试客户端提供的测试结果就可能越不精确，因为在基准调校过程中，Java VM的资源回收暂停（garbage collector pauses)占用了整个测试时间的较髙比重。运行HTTP请求的总数量越多，资源回收暂停变得意义更小，而让基准调校测试结果将更能显式Tomcat 的整体性能。您最好运行至少100, 000个HTTP请求以执行基准调校测试。另外，您可 以配置测试客户端，产生您喜欢的客户端线程数，但是，如果您将该线程数设置成查过 Tomcat的conf/server.xml文件中提供的连接器（Connector)最大线程数（maxThread), 那么实际不会有太大的帮助。在默认情况下将该线程数设置为150。如果您设置测试者超过这一数字，而且在更多的线程中产生了比Tomcat拥有的接收线程数和处理线程数还 要多的请求，就会影响性能，因为一些客户端清求线程将一直处于等待状态。最好是就 保留在连接器的最下线程数（Connector的maxThread)置下，如使用149个客户端线程。
Siege
使用执行与基准调校完全一样的工作，与命令行下的工作相似，只是您必须提供每 个线程要执行的请求数。如果您要用149个并发客户端，执行100，000个HTTP请求的基 准调校，那么必须告诉Siege，这149个客户端均需要产生671个请求（因为671x149 = 100,000),给Siege提供-b开关，以告诉Siege正执行基准调校测试，就像ab一样，这使 得的客户端线程在请求之间不存在等待的问题。在默认情况下，Siege在请求之间会 等待一段可配置的时间，但在基准调校模式下并不等待。例4-3显示命令行及基 准调校测试的结果。
示例4-3:用siege禁用keep-alive连接，执行基准调校
$ siege -b -r 671 -c 149 tomcathost:8080 ** siege 2.65 ** Preparing 149 concurrent users for battle. The server is now under siege... done. Transactions： 99979 hits Availability: 100.00 % Elapsed time: 46.61 secs Data transferred: 775.37 MB Response time: 0.05 secs Transaction rate: 2145.01 trans/sec Throughput: 16.64 MB/sec Concutiency： 100.62 Successful transsrtions 99979 Failed transactions: 0 Longest transaction: 23.02 Shortest transaction： 0.00
要获得最优基准调校结果，笔者推荐您使用ab,而不是siege。但是，对于您必须近似仿 真实际換作员的用户产生的Web流量进行其他种类的测忒时，就显得不适合了、因为 它在配置请求之间等待的时间数时没有提供特色，而确实以在请求之间等待一定随 机时间的方式提供了这一特色。除此之外，siege还可以从您选择的预置列表中请求随机 的URL。因此，siege可用于仿真操作员用户负载，而ab则不能。
Apache Jakarta JMeter
JMeter既对运行在图形模式下，也可运行在纯文本模式下。您可以在这两神模式下运行 JMeter测试计划，但必须在图形模式下创建测试计划。测试计划以XML配置文挡的方式 存储如果您只需要改变测试计划配置中的单个数字或字符串值，则您大概可以用文本 编辑器修改，但出于有效性校验的缘故，在图形化JMeter应用程序中编辑不失为一个不错的主意。
在试图运行JMeter以以对Tomcat进行基准调校测试之前，一定要确认您已用足够的heap内 存启动了JMeter的JVM，从而在基准调校中间不会因自身资源数据回收而降低速度。如果您在图形化方式下进行基准调校，这一点是非常重要的。在启动脚本中， heap内存大小的配置设置如下所示：
# This is the base heap size--you may increase or decrease it to fit your # system's memory availablity： HEAP="-XmsZ56m -Xmx256m"
它将彻底占满您能提供的heap内存，拥有的heap内存越多，需执行废弃数据回收的顿率 就越低。如果在运行JMeter的机器上拥有充足的内存，那么您应将256改变为更高的值， 如512。首先进行这样的处理是非常重要的，因为这一设置的默认值将改变基准调校测试的结果。
要为基准调校创建一个测试计划，首先要在图形模式下运行JMeter,如下所示：
$ bin/jmeter
JMeter的屏幕风格是左边为树状视图，右边是选择细节面板。在树状视图中选择内容， 会在右侧明细区显式详细的条目。要运行测试，必须在树状视图中组装和配置合适的对象，然后JMeter就可以运行测试并报告结果。
图4-1显示了含测试计划、整合完毕并准备运行的JMeler GUI,左边是树状视图，右边是 明细区。
图4-1 ： Apache JMeter GUI显式完整的组合测试计划
一旦编译并保存了测试计划，您就做好了运行基准调校的准本工作从上面的下拉菜 单中，选择File—Exit,退出图形化JMeter应用程序。然后，在命令行上以纯文本模式 运行JMeter,以执行基准调校，如下所示：
$ bin/jmeter -n -t tc-home-page-benchmark.jmx Created the tree successfully Starting the test Generate Summary Results = 99979 in 71.0s = 1408.8/s Avg: 38 Min: 0 Max: 25445 Err： 0 (0.00%) Tidying up ... ... end of run
注意在相同的硬件、Tomcat版本和相同的基准调校下，JMeter报告的每秒请求数（平均 1408.8个请求/秒）明显低干报告的请求数。这证实了JMeter的HTTP客户端比ab和siege的客户端要慢。您可以使用JMeter查明Web应用程序、Tomcat安装或JVM是否 发生了变化，Web网页响应的时间是快了还是慢了，但是您不能用JMeter决定服务器能 成功服务的最大请求数，因为JMeter的HTTP客户端显得比Tomcat的服务器模式要慢。
在准备好运行测试的时候，要么从下拉列表框中选择Run→Start,要么按齐【Ctrl】+【R】这样，基准调校测试就再次启动了，但在JMeter收集对应的响应数据时，就能 看到画出來的结果图。如图4-2显示了JMeter GUI用图形的方式显式测试结果。
图12: Apache JMeter以图形的方式显示测试结果
JMeter实现的图形化结果给您提供了运行测试的窗口通道，从而在命令行上运行之前， 您可以关注测试配置并修补测试配览中的问题，并根椐需要对其进行裁减。一旦认为测 试的SdS刚刚好，就保存不含Graph Results但含有Generate Summary Result树节点的测 试计划，从而以命令行的方式运行该测试计划，然后再以传递f测试类帮及可以在命令 行下运行的配置的新文件名保存它。使用您从命令下得到的结果作为权威结果。再次说 明的是，基准调校工具给您提供了更精确的基准调校结果，但没有提供像JMeter一样多的特性。
Web Server性能比对
在前面的章节中，您看到了一些HTTP基准调校客户端。现在，笔者给您展示Tomcat中 一个更有用的例子，演示基准调校从开始到结束的全过程，而且还产生了一些有助于配置Tomcat的信息，从而使其更好地为您的Web应用程序服务。
笔者已经调校了Tomcat的所有Web服务器实现，加上独立的Apache 及Apache httpd 连接到Tomcat的模块，以便査看每种配置服务于静态内容(content)的速度到底有多快。例如，Apache httpd比单独的Tomcat快吗？哪一种Tomcat独立Web服务器连接器实现 是最快的？哪种AJP服务器连接器实现是最快的？毎一种连接器到底有多快或者有多慢 呢？笔者通过至少硬件、OS和Java组合相同但基准校验配置不同的方法陈述了这些问题 的答案。
在基准调校过程中，笔者测试了服务于HTTP时的Web服务器性能，但没有对HTTPS (加密的HTTP)执行基准调校。在HTTP和HTTPS之间可能性能特性存在明显：差异，因为对HTTPS而言，服务器和客户端必须在网络的两个方向对数据加密和解密。在不同 的加密代码实现中，加密引起的过量开销大大降低了请求和响应速度。笔者没有对上述 Web服务器gd置执行HTTPS性能的基准调校。没有经过这种调校过程，许多人都想当然 地认为Apache Ar⑨i的HTTPS性能都要高于Tomcat的HTTPS性能，而通常人们是基于C比 Java代码要快作出这一判断的。前面执行HTTP基准调校驳斥了三种情况明显超出了笔者 进行的第四种基准调校场合，而第四种情况也不是明显优于C。没有基准调校的验证结 果，就无法知道哪种Web服务器Sd置是最快的。但是，要么是C加密代码最快，要么是 Java加密代码最快，这两者之间存在明显差别，幸运的是，Tomcat实现了这两种方式。
