ibm存储卷映射到服务器上_在IBM i上更新Tomcat服务器

这是一个分为两部分的系列文章的第二篇，该系列文章主要介绍IBM i Tomcat的启用。 第一篇文章讨论了如何将Tomcat放置在IBM i中，如何将其与i的HTTP Server关联以及如何在基于Tomcat的Web环境中运行Web应用程序。 作为基础构建文章，强烈建议您在继续本文之前阅读并遵循第一篇文章中概述的过程。

第二部分（本文）介绍了在Apache Software Foundation（ ASF）Tomcat上运行IBM i Web解决方案的最佳实践。 在基本了解如何在IBM i上安装和运行Tomcat之后，是时候关注Tomcat的性能和控件，以使Tomcat在IBM i上实现最佳性能。

本文使用第1部分中进行了修订并进行了修订的示例应用程序TomcatTestServlets，以演示如何通过使用或调整以下各项来提高Tomcat服务器的性能：IBM i子系统，JVM，Tomcat，用于i的HTTP Server以及Web应用程序本身。

调整应用程序服务器时，请牢记以下一些初步事项：

• 除了应用程序服务器之外，其他几个因素也会影响性能，包括硬件，操作系统配置，对系统资源的需求冲突，后端数据库资源的性能，网络延迟等。 进行绩效评估时，您必须考虑这些项目。
• 该示例应用程序只是一个演示，不能保证所有调整参数都完全适合您的应用程序。 因此，对您自己的应用程序进行集中的性能测试和调整对您而言很重要。
• 性能提高可能涉及牺牲应用程序或应用程序服务器中的特定级别的功能。 在评估性能调整更改时，必须仔细权衡性能和功能之间的权衡。 例如，当为i调整HTTP Server的性能时，将禁用域名服务器（DNS）查找功能以加快传输速度。
• 本文重点介绍调整应用程序性能的原理。 虽然每个应用程序都有其独特的特性，但是这些原理适用于大多数调优工作。

样例应用程序概述

TomcatTestServlets示例应用程序用于使用IBM®Toolbox for Java提供的IBMDB2®JDBC驱动程序来测试数据库查询的吞吐量。 我们更新了此应用程序，以使其不仅可以用作数据库功能测试的出色应用程序，而且还可以提供一组标准的工作负载来衡量应用程序服务器的性能。 请参阅可下载资源部分中的应用程序的TomcatTestServlets.war文件（可以从TomcatTestServlets.zip文件中提取）。 图1显示了该应用程序体系结构的高级概述。

图1.使用Tomcat应用程序服务器的示例应用程序概述

建立基线

在进行任何改进之前，必须建立应用程序当前性能的基准。 这很重要，以便可以以有用且可量化的方式测量任何更改。 调整性能时，有无数的指标可供考虑，但是应用程序吞吐量和响应时间是更重要的两个。

为了测试Web应用程序的性能，需要一个易于使用的测试工具。 您可以使用多种测试工具。 一些最常用的工具是：

• Apache JMeter –由Apache设计的免费测试工具，用于加载测试功能行为并衡量性能
• Apache HTTP服务器基准测试工具 –由Apache设计的免费测试工具，用于基准测试Apache超文本传输​​协议（HTTP）服务器
• IBM Rational Performance Tester （RPT）–由IBM开发的商业性能测试工具

可以从Apache网站免费获得Apache工具。

本文使用RPT作为测试工具，但为Apache JMeter提供了简短的介绍。 Apache JMeter是一个100％纯Java应用程序，旨在驱动和测量负载测试功能行为。 它可用于模拟服务器，网络或对象上的重负载，以测试其强度或分析不同负载类型下的整体性能。 使用Apache JMeter，您可以轻松地创建性能测试，如图2所示。

图2.使用Apache JMeter创建性能测试

测试结束后，您可以在“摘要报告”，“响应时间图”和“图结果”部分中找到统计数据。

IBM RPT在加载和测试功能行为以及衡量性能方面非常有效。 使用RPT，我们可以创建一个性能计划，以模拟运行300分钟的情况（持续5分钟）。 我们将不讨论设置或部署RPT。 那将是另一篇文章的讨论。 我们将展示该工具的功能，并了解如何使用它更好地了解应用程序的服务器性能。

图3.在RPT中创建性能计划

首先，将所有与Tomcat和HTTP Server for i相关的配置都保留为默认值，然后运行测试计划。 这为我们提供了一个基准，可以用来衡量任何改进。 图4和图5显示了吞吐量和响应时间基线。

吞吐量统计：

图4.从RPT调整之前的吞吐量统计

在图4中：

• 水平x轴表示此工作负载基准的运行时间。
• 垂直y轴表示实时吞吐量，即从服务器检索的数据。
• 蓝线表示吞吐量。 首先，所有300个用户都被激活。 启动所有线程的预热阶段覆盖了前150秒，这导致吞吐量快速增加。 下一个时段用红色折线标记，在此期间，用户数量稳定。 这导致吞吐量在此期间趋于稳定。 最后，所有用户都急剧失活，吞吐量在短时间内下降。

响应时间统计：

注意：RPT从测试用例开始就开始计算响应时间统计信息，而不是从激活所有用户的时间开始计算。

图5.从RPT调整之前的响应时间统计

现在，您对应用程序和基准统计数据有了基本的了解。 以下各节描述了一些常规的调整技术，以提高在Tomcat上运行的IBM i Web应用程序的整体性能。

在自己的子系统中运行Tomcat

子系统是单个预定义的操作环境，系统可通过该操作环境来协调工作流程和所使用的资源。 在IBM i上，这是一种允许您分离和控制工作负载的机制。 默认情况下，Tomcat作业在QINTER子系统中运行，该子系统运行所有交互式作业。 当用户和工作较少时，此方法效果很好。 但是，随着QINTER的用户数量和工作量的增加，QINTER子系统有时不足以进行这组工作。 此外，将应用程序服务器留在QINTER子系统中还可能使其他交互式工作负载（例如，绿屏）潜在地影响Web应用程序的性能，因为交互式服务器和应用程序服务器都在争夺同一资源。 因此，我们希望在其自己的子系统中运行Tomcat作业。 在单独的子系统中运行可以具有以下优点：

• 由于对识别哪些子系统上正在运行的工作有更好的智力控制，因此提高了系统上工作的可管理性。
• 提供禁止用户在特定时间段访问系统的功能。
• 提高可伸缩性和可用性。 通过让一个子系统为更少的用户工作，子系统就不会那么忙碌，并且可以对它处理的工作请求做出更快的响应。
• 提高了容错能力，这对于交互式作业（例如Tomcat作业）尤其重要。
• 缩短子系统启动时间。
• 提供对应用程序服务器所需内存的更好控制。
• 使用工作负载组来控制可用于应用程序服务器的处理器数量。
• 减少其他工作负载影响应用程序服务器性能的可能性

在开始之前，让我们突出一些经常提到的关键术语：

表1.子系统相关概念

术语	描述
子系统	定义系统资源以运行作业。 例如，内存池和最大作业数。
子系统说明	包含子系统属性的对象。 它用于创建和定义子系统。
作业队列条目	属于子系统描述。 告诉子系统在作业队列中拾取作业以运行
作业队列	作业被提交到作业队列中，然后在子系统中运行。
路由输入	属于子系统描述。 它告诉作业队列中带有此处描述的“标题”（路由数据）的子系统作业只能被拾取。
职位描述	系统用来定义作业的一组特征。 作业描述中指定的属性指示系统以所需方式运行作业。

图6. IBM i上的子系统和作业路由概述

熟悉基本概念之后，让我们将Tomcat应用服务器配置为在其自己的子系统中运行。 有关架构，请参见图6。

第1步–创建一个新库

创建一个名为TOMCAT7的新库，用于存储所有IBM i本机对象，例如，作业队列条目，路由条目，作业描述等。

CRTLIB TOMCAT7

步骤2 –建立工作Create列

这是作业开始运行之前提交的位置。 当然可以将其提交到QBATCH或其他队列中，但是再次，现在您正在与该队列中的其他工作竞争。 我们在这里展示了一种自定义方式，可以最大程度地控制。 在上面创建的库中创建名为TCJOBQ的作业队列条目。

CRTJOBQ JOBQ(TOMCAT7/TCJOBQ)

步骤3 –建立工作描述

这定义了作业的运行方式。 根据需要根据您的特定要求对其进行自定义。 在上述库中创建一个名为TCJOB的作业描述，并将其与您刚创建的作业队列相关联。

CRTJOBD JOBD(TOMCAT7/TCJOB) JOBQ(TOMCAT7/TCJOBQ)

步骤4 –建立课程

该类定义作业的处理属性。 作业使用的类在启动作业时使用的子系统描述路由条目中指定。 我们只需要在这里上课。 在上面创建的库中创建一个默认的名称为TCSBS的TCSBS。

CRTCLS CLS(TOMCAT7/TCSBS)

步骤5 –创建子系统描述

这是Tomcat服务器作业实际运行的地方。 使用与上一节中定义的类（TCSBS）相同的名称创建子系统。 需要为子系统定义的重要组件是该子系统中运行的所有作业将使用的内存池。 可以使用两种类型的内存池，即基本内存池和专用内存池。 基本内存池包含许多子系统共享的系统上所有未分配的主存储。 但是， 专用内存池 （也称为用户定义的内存池）包含特定数量的只能由单个子系统使用的主存储。 使用专用内存池意味着您可以管理该子系统的内存，而不会受到系统中其他子系统或作业的干扰。 建议对要确保不受同一系统上其他工作影响的任何工作负载创建专用内存池。 如果要使用基本内存池，请运行以下CL命令：

CRTSBSD SBSD(TOMCAT7/TCSBS) POOLS((1 *BASE))

如果要创建自己的专用于Tomcat的专用池，请发出以下CL命令。

CRTSBSD SBSD(TOMCAT7/TCSBS) POOLS((1 1024 500 *MB))

注意：在命令中， 1024指定新存储池的大小， 500指定可以在该池中同时运行的最大线程数。 您可以根据需要配置私有内存池。 本文创建了一个专用内存池，并将其池大小/线程号设置为1024 MB / 500。 内存和活动线程是应用程序性能的组成部分，需要密切关注。 如果您的应用程序启动受到内存限制或线程用完，则可能会对应用程序性能产生不利影响。 对于任何基于Java的应用程序，内存和可用线程数是造成性能限制的主要因素之一。

步骤6 –添加作业队列条目

以下命令告诉子系统它应该搜索哪个作业队列以搜索要运行的作业。 在这里，我们让TCSBS搜索TCJOBQ。

ADDJOBQE SBSD(TOMCAT7/TCSBS) JOBQ(TOMCAT7/TCJOBQ)

步骤7 –添加路由条目

将路由条目添加到子系统，以定义作业选择标准和用于启动作业的参数。

ADDRTGE SBSD(TOMCAT7/TCSBS) SEQNBR(10) CMPVAL(*ANY) PGM(QSYS/QCMD)

步骤8 –启动Tomcat服务器

所有对象均已设置； 让我们从在新创建的子系统中启动Tomcat服务器开始测试。

1. 启动您在步骤5中创建的子系统。

   STRSBS SBSD(TOMCAT7/TCSBS)

2. 将作业提交到定制的子系统中，以启动Tomcat应用程序服务器。 在我们的例子中，启动Tomcat的脚本位于/home/download/apachetomcat7.0.28/bin/startup.sh

   SBMJOB JOBQ(TOMCAT7/TCJOBQ) JOBD(TOMCAT7/TCJOB) CMD(QSH CMD(
         '/home/download/apache-tomcat-7.0.28/bin/startup.sh’))

步骤9 –创建自定义的CL命令以启动Tomcat服务器

默认情况下，我们需要运行两个复杂的命令来启动子系统，并提交作业以启动Tomcat应用程序服务器。 这很不方便。 让我们创建一个C程序并将其绑定到一个名为STRTMC的CL命令以使其变得更容易。

1. 首先，创建源代码文件[此示例位于/ home / downloads中的strtomcat7.c（请参阅可下载资源部分）]，以启动子系统并运行tomcat启动脚本。 下面是该程序的代码。

   #include <stdio.h>
   #include <unistd.h>
   #include <stdlib.h>
   #include <sys/stat.h>
                           
   int main(int argc, char ** argv)
   {
           char cmdbuf[4096];
           //make command string, pass the parameter to script.
           sprintf(cmdbuf, "SBMJOB JOBQ(TOMCAT7/TCJOBQ) \
           JOBD(TOMCAT7/TCJOB)\
           CMD(QSH   CMD('/home/download/apache-tomcat-7.0.28/bin/startup.sh'))"); 
                           
           // we do not expect the output screen (default console) with
           // a "press any key to continue". This program should end immediately.
           umask(0);
                           
           // ensure subsystem is up
           system("STRSBS SBSD(TOMCAT7/TCSBS)");
                           
           // submit the job
           system(cmdbuf);
                           
           return 0;
   }

2. 创建C程序。

   CRTBNDC PGM(TOMCAT7/STRTMC) SRCSTMF('/home/download/strtomcat7.c')
   TEXT('Tomcat start script invoker')

   这是内容的示例：

   *************** Beginning of data*************************************
   0001.00 CMD    PROMPT('START TOMCAT7') 
   ****************** End of data****************************************

3. 创建我们的自定义CL命令。

   CRTCMD CMD(TOMCAT7/STRTMC) PGM(TOMCAT7/STRTMC)
   SRCFILE(TOMCAT7/CMDSRC) SRCMBR(STRTMC)

   该命令名为STRTMC，位于TOMCAT7库中。 它实际上在TOMCAT7中调用程序STRTMC。

4. 运行STRTMC命令以启动Tomcat应用程序服务器。

   TOMCAT7/STRTMC

Tomcat作业现在正在定制的子系统TCSBS中运行

这些步骤说明了如何创建定制的CL命令以在其自己的子系统中启动和运行Tomcat应用程序服务器。 您可以参考这些步骤并进行修改，以创建另一个CL命令ENDTMC，以方便停止Tomcat应用程序服务器（您可以在本文的“可下载资源”部分中找到源代码endtomcat7.c）。

调优JVM

Tomcat应用程序服务器基于Java，并在JVM上运行。 这意味着JVM可能会对Tomcat的整体性能产生一些影响。 下一节介绍了通过优化JVM来提高Web应用程序性能的建议。

注：本文中的此示例基于IBM i 7.1。 IBM i上的JVM是IBM Java技术。 在这里，我们对IBM Java技术进行了一些基本调整。

例如，我们可以编辑配置文件/home/download/apachetomcat7.0.28/catalina.sh，并在此文件中添加以下行以配置某些JVM选项。

JAVA_OPTS="$JAVA_OPTS -Xquickstart -Xms2048M -Xmx2048M

以下是刚刚设置的属性的描述。

• -Xquickstart： Xquickstart用于使即时（JIT）编译器以优化的子集运行，这使短期运行的应用程序性能更好。 在本文中，此指令已启用（默认值已禁用）。

• -Xms2048M –Xmx2048M： Xms和Xmx用于定义JVM使用的堆大小。

Xms定义堆的初始大小，Xmx定义堆的最大大小。

如果有足够的内存，则可以将两个属性设置为相同的值，以满足应用程序的最大内存需求，以避免在垃圾回收后重新分配内存。 本文中，这两个属性设置为2048 MB，因为本文中的示例在峰值负载期间需要大量内存。 但是，如果内存有限，则可以将Xms设置为满足应用程序的平均内存要求，而将Xmx设置为满足应用程序的最大内存要求。 例如，您可以将Xms设置为512 MB，将Xmx设置为2048 MB。

调整Tomcat

Tomcat服务器具有许多调整参数，可以调整这些调整参数以显着提高Web应用程序的性能（或者，如果不小心，可能会损害应用程序的性能！）。 本节介绍了在Tomcat的配置文件中定义的一些设置。

表2.关键术语

术语	描述
连接器	表示外部客户端向特定服务发送请求和从特定服务接收响应之间的接口。
货柜	表示其功能是处理传入请求并创建相应响应的组件。
主办	是处理特定虚拟主机的所有请求的容器
语境	是处理特定Web应用程序所有请求的容器

本节说明这些组件的调整技术。 我们将打开许多不同的文件，并更新在这些配置文件中找到的一些重要属性。

• 连接器 （/home/download/apachetomcat7.0.28/conf/server.xml）

  <Connector port="8009" Protocol="AJP/1.3"
   connectionTimeout="20000" redirectPort="8443" maxThreads="300" maxSpareThreads="100"
   minSpareThreads="40" maxKeepAliveRequests="200" socketBuffer="12000"
   acceptCount="300" enableLookups="false" compression="on"
   compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"
  />

  • maxThreads=<val>:此属性指定此连接器将创建的最大请求处理线程数。 这确定了可以处理的最大同时请求数。 此属性的默认值为200。此属性没有最佳值，因为过多的线程可能由于处理器的切换操作而导致其他成本。 对于此示例，该属性设置为300。这是可能需要反复试验才能确定最佳值的属性。

  • maxSpareThreads=<val>:此属性指定在线程池开始停止不必要的线程之前允许存在的未使用请求处理线程的最大数量。 此属性的默认值为50。建议为该属性分配一个较高的值以应对紧急情况。 对于此示例，该属性设置为100。

  • minSpareThreads=<val>:此属性指定在首次启动此连接器时创建的请求处理线程数。 该属性的默认值为25。建议为该属性分配一个较高的值。 对于此示例，该属性设置为40。

  • maxKeepAliveRequests=<val>:此属性指定在服务器关闭连接之前可以通过管道maxKeepAliveRequests=<val>:的HTTP请求的最大数量。 此属性的默认值为100。建议为该属性分配一个相对较高的值，以使更多的HTTP请求能够通过管道传输。 对于此示例，该属性设置为200。

  • socketBuffer=<val>:此属性指定为套接字输出缓冲提供的缓冲区的大小。 此属性的默认值为9000字节。 建议为该属性分配一个较高的值以生成一个良好的缓冲区。 对于此示例，该属性设置为12000字节以应对高级峰值负载数据。

  • acceptCount=<val>:当所有可能的请求处理线程都在使用中时，此属性指定传入连接请求的最大队列长度。 该属性的默认值为100。建议为该属性分配较高的值。 对于此示例，该属性设置为300。

  • compression=<val>:此属性指定是否压缩要传输的数据。 此属性和compressableMimeTypes属性一起使用。 尽管这两个属性可以减少传输的数据，但是我们不能保证它们可以加快数据的传输速度，因为压缩操作也会花费时间。 结果，您必须使用不同的值进行一些测试，以查看这两个属性是否确实节省了时间。 如果未指定，则此属性设置为off。 对于此示例，压缩设置为开。

  • compressableMimeTypes=<val>:此属性指定要压缩的内容。 默认值为text / html，text / xml，text / plain。 对于此示例，属性设置为“ text / html，text / xml，text / javascript，text / css，text / plain”。

• 主机 (/home/download/apachetomcat7.0.28/conf/server.xml)

  <Host name="localhost" appBase="webapps"
      unpackWARs="true" autoDeploy="false">

  • autoDeploy=<val>:此属性指示在Tomcat运行时，Tomcat是否应定期检查新的或更新的Web应用程序。 更新的Web应用程序或上下文XML描述符触发Web应用程序的重新加载。 此属性的默认值为true 。 对于开发环境，可以将此属性设置为on。 但是，建议在生产环境中将此属性设置为false 。

• 上下文 (/home/download/apachetomcat7.0.28/conf/context.xml)

  <Context swallowOutput="true" reloadable="false">

  • swallowOutput:此属性通过使Web应用程序重定向到Web应用程序记录器，将输出定向到System.out和System.err。 我们希望将此属性设置为true ，以便更轻松地解决Web应用程序问题。

  • reloadable=<val>:此属性控制Tomcat的Java™类热部署。 它使Tomcat监视/ WEB-INF / classes /和/ WEB-INF / lib中的类以进行更改，并在检测到更改时自动重新加载Web应用程序。 此属性的默认值为false 。 对于开发环境，可以将此值设置为true以便于开发。 但是，建议在生产环境中将此属性保留为false ，因为这会大大降低运行时的工作量。

调优HTTP服务器

HTTP服务器是通用Web服务器。 它旨在提供灵活性，可移植性，安全性和性能之间的平衡。 HTTP Server for i包含许多其他优化，以提高我们IBM i环境的吞吐量和可伸缩性。 默认情况下，其中大多数改进都是启用的。 本节介绍了可以配置为i调整HTTP Server来提高Web应用程序性能的选项。

有关示例应用程序，请参考HTTP服务器配置。 您可以在“ / www / <http实例名称>”找到配置文件。 粗体属性是我们将要检查的属性。

LoadModule jk_module /QSYS.LIB/QHTTPSVR.LIB/MOD_JK.SRVPGM
JkWorkersFile /www/httpserver/conf/workers.properties
JkLogFile /www/httpserver/logs/jk.log
JkLogLevel warn
JKMount /manager/* worker1
JKMount /TomcatTestServlets/* worker1
Listen *:5555
DocumentRoot /www/httpserver/htdocs
                
ThreadsPerChild 120
AcceptThreads 12
LogLevel warn 
HostNameLookups off 
CacheLocalFile /home/download/apachetomcat7.0.28/webapps/TomcatTestServlets/data/*.xml
CacheLocalFile /home/download/apachetomcat7.0.28/webapps/TomcatTestServlets/data/*.xsl
DynamicCache on 
LiveLocalCache off
CacheLocalSizeLimit 51200
CacheLocalFileSizeLimit 90000

ThreadsPerChild:此伪指令用于指定每个服务器子进程的最大线程数。 如果您没有为指令指定值，那么它将继承全局HTTP服务器设置（默认值为40，可以使用CHGHTTPA命令进行更改）。 用户应根据实际需要设置该值。 该值会极大地影响性能。 例如，较小的值将导致HTTP服务器响应缓慢，而较大的值将导致资源浪费。

子进程在启动时创建线程，从不创建更多线程。 此数字应该足够高，以处理高峰HTTP服务器负载期间预期的同时连接数。 增加此伪指令的值时，应小心考虑系统内存和处理能力。 将此属性设置得太高会消耗大量系统资源，从而会对HTTP服务器和系统性能产生不利影响。 如果在高峰负载期间达到了服务器线程的最大数量，则会在套接字连接请求积压中放置其他连接请求，直到服务器线程变得可用于为连接请求提供服务。 随着服务器使用异步I / O，每个服务器线程只能处理已收到请求的连接。 线程可以在等待现有连接上的新请求时处理其他连接。

AcceptThreads:此伪指令指定每个服务器子进程的最大接受线程数。 如果未为此指令指定值，则服务器每个进程使用四个接收线程的限制。 接受线程用于接受来自客户端的新连接，然后将这些请求转发到HTTP服务器工作线程进行处理。 可能需要更改此指令的值以反映正在接受的并发连接数。 如果与Web服务器的大量连接大约在同一时间开始，则可能需要将此数字调整为更高的值。 这些接受线程是在启动时创建的，该过程永远不会创建更多线程。 （默认值为4，最大数量为20）。

您可以使用Web管理GUI中的“ 实时 服务器统计信息”链接查看在调整HTTP服务器之前有多少空闲线程可用。 如果在激活所有300个用户之后很长连续时间内没有空闲线程可用，表明服务器非常繁忙，则可以考虑将ThreadsPerChild指令更改为更高的值。

图7.调整之前的实时服务器统计信息

这表明HTTP服务器很长时间都处于忙碌状态，并且所有新的客户端请求都需要等待，直到线程可用为止。 对于这种情况的建议是将ThreadsPerChild指令的值增加到一个更合理的数字。 对于此示例，该属性设置为120，以确保在应用程序运行到其峰值负载时有足够的空闲线程。 用户可以根据应用程序的实际要求设置此指令。 图8显示了调整此属性后的实时服务器统计信息。

图8.调整后的实时服务器统计信息

LogLevel:此伪指令调整错误日志中记录的消息的详细程度。 对于开发环境，可以将此指令设置为相对较低的值，例如，debug或info以生成详细的日志消息，以查找错误和调试问题。 但是，对于生产环境，应将此指令设置为较高的值，以减少日志文件中指定的详细信息。 较低的日志级别可能会影响Web应用程序的性能。 对于此示例，伪指令被设置为其默认值（警告），就好像它是生产环境一样。

HostNameLookups=<val>:该指令启用DNS查找，并使HTTP服务器执行反向查找，以将IP地址转换为主机名和域。 该指令的默认值是off以节省那些确实不需要反向查找的站点的网络流量。 但是，如果确实需要DNS查找（例如，需要在访问日志中记录域名的用户），则可以将此指令设置为on 。 对于此示例，此伪指令设置为默认值off因为DNS查找会占用大量额外时间和资源。

如果您有经常访问且变化不大的静态文件（例如HTML，JPEG，JS和CSS），则可以通过以下设置以下指令为这些文件分配缓存文件。 如果没有，您可以忽略这些指令。 将这些类型的静态对象放在缓存中可以节省大量时间来查找文件。

CacheLocalFile:此伪指令用于指定每次启动服务器时要加载到服务器内存中的文件的名称。 您可以在配置文件中多次出现此伪指令，从而可以指定许多文件。 通过将最常请求的文件加载到服务器的内存中，可以改善服务器对这些文件的响应时间。 例如，如果在启动时将服务器的欢迎页面加载到内存中，则服务器处理该页面的请求的速度要比每次必须从文件系统读取文件的速度快得多。 在示例应用程序中，将缓存XML和XSL文件。

DynamicCache:此伪指令用于指定是否要服务器动态缓存经常访问的文件。 将动态缓存指令设置为on指示服务器缓存最常访问的文件，从而提高性能和系统吞吐量。

LiveLocalCache:此伪指令用于指定在修改缓存文件时是否更新缓存。 如果将其设置为on ，则在响应对存储在内存中的文件的请求之前，服务器将检查自服务器启动以来文件是否已更改。 如果文件已更改，则服务器将使用更新的文件来响应此请求，然后从内存中删除较旧的文件版本。 如果您希望用户请求缓存的文件来接收具有最新更新的文件，请将此伪指令设置为on的默认值。 将此指令设置为off是性能最佳的设置。

CacheLocalSizeLimit:此伪指令用于指定要允许文件缓存的最大内存量（以千字节为单位）。 您必须使用CacheLocalFile指令或将DynamicCache设置为on来指定要缓存的文件。 当文件被缓存时分配存储空间。 对于此示例，该伪指令设置为4000，而不是默认值2000，以应对重载。 用户可以根据自己的要求设置此指令。

CacheLocalFileSizeLimit:此伪指令用于以字节为单位指定将放置在本地内存缓存中的最大文件。 大于CacheLocalFileSizeLimit指定的值的文件不会放置在缓存中。 这样可以防止仅由少量非常大的文件填充高速缓存。 对于此示例，伪指令设置为120000，而不是默认值90000。

快速响应缓存加速器（FRCA）是另一种有用的缓存技术。 它完全在IBM i机器接口（MI）下运行，该接口允许FRCA作为系统许可的内部代码任务有效地执行，从而避免了切换到用户级别服务器线程（例如i的HTTP Server）的昂贵工作。 FRCA可以以用于静态内容的本地缓存形式或以用于动态内容的反向代理缓存形式提供Web内容。 在提供Web内容时，FRCA的性能比传统的缓存技术好得多。 但是，FRCA不支持安全套接字层（SSL）和传输层安全性（TLS）。 此外，FRCA不能保护未经身份验证的用户访问未经身份验证的文件。 因此，如果不需要保护Web应用程序的内容或通过特定验证对其进行访问，则FRCA是最快的选择。 您也可以考虑使用多种方法。

以上所有调优技术只是针对i的HTTP Server性能调优的冰山一角。 如果要进一步研究，可以参考《 i Redbooks HTTP Server》中的第10章， 从HTTP Server获得最佳性能 。

调整Web应用程序

既然我们已经尽了最大的努力来定制Tomcat的相关配置来提高Web应用程序的性能，那么现在该看看Web应用程序本身的改进了。 此过程更加复杂，但是性能提升可能成倍增加。

The best time to think about optimizing the web application's performance with Tomcat is during the development phase. So, consider all the design choices carefully. You can also refer to the following general tips.

• JSP pre-compilation : Pre-compile JSP files before deploying the web applications. This means that a JSP file does not need to be compiled when running it the first time. It can also protect the source code of the JSP files. The alternative is to allow the JSP files to be compiled dynamically on first touch.
• Cache dynamic page output : If each request for a page generates the same output, consider temporarily caching the generated output.
• Tactics selection : Consider factors such as the suitability of protocol for the project. For example, if you are loading large amounts of data and need high performance, XML might not be the appropriate choice.
• Database connection pooling : DB connection pool can significantly influence the web application's flexibility and robustness.
• Database object caching : Using middleware to persist and cache objects from database can significantly improve performance.

With all these techniques, you are well on your way to great Tomcat performance on application level.

Tuning effect

After completing all these tuning techniques, let's verify whether the web application's performance is better. Generate statistics with exactly the same testing case using RPT. Figure 9 and Figure 10 show the statistics of the throughput and response time.

Figure 9. Throughput statistics after tuning from RPT

Figure 10. Response time statistics after tuning from RPT

Now compare the statistics before and after Tomcat tuning using RPT. Figure 11 shows the comparison statistics.

Throughput statistics:

Figure 11. Throughput comparison statistics before and after tuning from RPT

In Figure 11:

• The horizontal ordinate represents the time this baseline cases spend.
• The longitudinal ordinate represents the real-time throughput.
• The red line represents the period that a stable number of users are sending or receiving data.
• The blue curve represents the throughput before tuning.
• The green curve represents the throughput after tuning.

Response time statistics:

Figure 12. Response Time statistics comparison before and after tuning

It can be seen from Figure 12 that at a stable phase (all users are activated), the throughput is increased by about 7% and the response time is deduced by about 2%. It proves that the web application's performance on IBM i is surely improved after all the tuning techniques.

摘要

These performance adjustments are intended to help you better understand the many factors that can impact your web applications. The only way to determine what works best in your environment is to invest in the necessary performance evaluation. Much is done through trial and error methods. To help you know when to stop, be sure you understand what your performance requirements are before you start tuning.

翻译自: https://www.ibm.com/developerworks/ibmi/library/i-run-asf-tomcat-on-ibmi/index.html