WebSphere优化如何通过 20 的工作获得 80 的性能改善Word文档格式.docx
《WebSphere优化如何通过 20 的工作获得 80 的性能改善Word文档格式.docx》由会员分享，可在线阅读，更多相关《WebSphere优化如何通过 20 的工作获得 80 的性能改善Word文档格式.docx（19页珍藏版）》请在冰豆网上搜索。
一些应用程序拥有庞大的HTTPSession；
一些应用程序执行了select*并试图将所有数据缓存到中间层中（有千兆的数据也那么干！
）。
本文将向您介绍一些很好的优化技巧，但只有应用程序本身可以带来真正显著的结果。
是的，这意味着应用程序开发人员和服务器管理员必须定期相互沟通！
本文涵盖以下内容：
性能测试环境o找出薄弱环节o测试工具o模拟本文所使用的环境环境卫生o获得性能基准数o优化记录/日志oCPU使用率o内存使用率o其他环境因素实现Jython经验优化oJVM冗余垃圾回收（GC）oJVM设置o连接池设置o启用Servlet缓存oWeb容器线程池o高级优化思想：
SpecJ全面披露性能测试环境找出薄弱环节您需要一个尽可能反映生产环境的测试环境。
如果您使用的是几千兆的数据仓库，则测试系统可能需要小一些。
但是性能和生产环境之间的任何差异都可能引起高开销的推断错误。
大型企业没有任何理由宣称它们无法提供同等规模的性能测试服务器。
小测试环境可能无法暴露某些方面（例如锁操作、日志记录、HTTPSessions、垃圾回收、连接池、CPU、内存、数据库、网络或应用程序）现有的问题。
测试工具找准方向创建实际测试工具是有效优化的关键步骤。
如果您在测试服务器上施加的工作负载无法反映出站点中实际发生的情况，则您的优化将无法解决问题！
有很多开放源代码的软件测试产品和商业软件测试产品（请参阅下面的参考资料）。
您可以通过查看现有的服务器日志来了解实际测试场景。
当引入新的应用程序时，这些历史记录对您是没有帮助的，所以必须有最好的设想。
测试工具打破极限优化旨在发现问题并修复它们。
如果测试没有使服务器负载达到临界点，则有些问题将检测不到，所以要确保服务器的负载超过您预期的最高峰流量。
这样做将使您获得测试工具定义中的误差幅度。
优化最差情况下的负载，这样您在投入生产时就已经拥有更高负载下的性能值。
于是，您将知道您的安全幅度有多大以及什么时候需要为非常流行的应用程序进行扩容。
应用程序的创建者不应该开发测试工具，因为他们知道假定的边界条件，会有意避免创建超出这些边界的测试用例。
生产工作负载可没有这么友善！
一些测试提供的用户数是适度增长的，从而生成相当线性化的性能曲线图。
但是实际的用户到达率往往是集群化且不规则的，所以在投入生产环境之前需要对这些条件进行测试。
如果您的测试计算机上有其他用户，则他们必须知道您的测试计划否则他们可能认为他们遭遇某种严重的问题，例如拒绝服务攻击。
本文所使用的测试环境本文中的结果来自IBM培训计划，它使用WebSphereTrade6内部基准来训练学员在高压竞争环境下进行性能优化。
该测试环境使用RedHatEnterpriseLinuxV3、WebSphereApplicationServerV6.0.1、DB2V8.2和ApacheJMeter。
这些产品将安装在VMWareV5.0下。
两台IBMThinkPad便携式计算机使用以太网交叉电缆相连接。
应用服务器运行在一台计算机上，而测试工具和数据库运行在另一台计算机上。
为了简化性能优化环境和降低出现错误的可能性，您应该使用shell脚本来启动不同的组件。
下面的清单1显示了一个名为go_trade6的示例脚本。
该脚本从端到端启动基准，包括WebSphereApplicationServer、DB2服务器、JMeter程序和用于监控top和vmstat的xterm。
清单1.启动测试环境所有组件的脚本xterm-exectop&
xterm-execvmstat3&
su-cdb2startdb2inst1#su-coninitinformixstartWASmozilla&
#starttestharnesscd/root/trade6/jakarta-jmeter-2.0.2/bin/opt/IBMJava2-141/bin/javaApacheJMeter.jar-ttradebuysell.jmx&
#readwastecpu.cwastecpu&
wastecpu&
exportPATH=$PATH:
/opt/IBM/WebSphere/AppServer/bin环境卫生获得性能基准数在进行任何更改之前，获得性能基准数是很重要的，因为只有与基准进行比较才能确切说明系统变快还是变慢。
在运行基准测试或其他性能测试时，必须谨慎地控制系统上的其他工作。
例如，如果您的数据库用于事务处理和繁重的决策支持（DSS）查询，则可以确定非预定的DSS查询将牺牲您的事务性能。
如果您在不知道DSS会有干扰时试图优化此环境，则将错误地得出结论：
系统的性能“已优化，但不可预测”。
实验示例的性能基准（使用JMeter）如下面的图1所示。
可以通过Run菜单下拉列表启动一项测试或清除先前的所有数据以进行下一次测试。
图1.使用JMeter的性能基准：
37毫秒响应时间基准性能表明平均响应时间为37.6毫秒（请看JMeter帧的右下角）。
您可以对不同的度量进行优化，例如吞吐量、中值响应时间、响应时间偏差或其他某种优化目标。
首先确定优化目标，然后弄清楚如何优化系统才能实现此目标。
如果工作负载很大而且系统优化不好，则需要花很长时间才能获得基准性能值。
您可以使用小型测试工具来缩短一些早期测试的时间，还可以获得系统输出的详细信息。
确保数千次点击的次秒级响应不会只是应用程序错误页面的详尽测试。
JMeter提供测试活动日志。
您可以定义一个文件（例如/tmp/jmeter.out）来包含HTTP请求响应活动的返回代码。
在下面的下载部分，您将发现JMeter的两个不同的测试文件。
一个是完全测试，另一个标为“Small”。
Small测试也启用了输出收集功能，以便您可以看到请求-响应的结果。
在实验测试中，计算机是完全满负荷的图1右下角的蓝色实框表示100%的CPU使用率。
图形指示器和运行top命令的xtermBoth都指示CPU使用率的问题。
查明什么占用了CPU时间需要费些周折。
没有足够的CPU和内存，服务器（WebSphereApplicationServer或其他任何服务器）将不能很好地运行。
如果您在没有空闲CPU时或者在操作系统需要交换虚拟内存的地方试图优化服务器，则无法使其变得很快。
下一部分将描述如何检测CPU或内存受限的系统以及如何修复它们。
优化日志一些优化更改将使系统运行得更快，而一些将使之运行得更慢。
记录您做了什么更改以及为什么这样更改将使优化过程更简单也更顺利。
下面是一个非常简单的配置日志格式不是很重要，只要您每次记录一些关键数据点即可。
一个好的过程是将更改作为注释放在配置文件中。
示例优化日志条目DateTime:
_Name:
_ParameterChanged_Why?
_How?
_NewPerformance_millisecondsKeep_Remove_How?
_CPU使用率在进行任何优化前，系统必须有可用的CPU周期。
任何在服务器上运行的不是很有用的程序都应该停止或禁用包括在服务器上运行的漂亮屏幕保护程序！
检测CPU受限的系统的最佳方式是运行top命令它是Linux/Unix性能工具的“瑞士军刀”：
图2.top命令在右上角，“idle”处于0.0%，所以我们知道计算机已竭尽全力在运行。
“COMMAND”栏中的进程列表显示占用最多CPU周期的两个程序称为wastecpu。
如果您阅读清单2中的注释，您会发现可以将wastecpu杀死。
清单2.wastecpu源代码/*ifyoureadthiscommentbeforeyoukilledwastecpuyoudidgood!
WastecpuismeanttosimulateaproductionapplicationandthepurposeistotrainpeoplenottokillANYTHINGwithoutknowingwhatitdoes.*/#includemain（）inti;
for（i=0;
ivariablejvmisprintjvmprintAdminConfig.show（jvm）printAdminConfig.show（jvm）printchangejvmsettingsAdminConfig.modify（jvm,verboseModeGarbageCollection,true）AdminConfig.save（）printaftersave:
printAdminConfig.show（jvm）#onmysystemtheoutputofverbosegcisinthefile:
#/opt/IBM/WebSphere/AppServer/profiles/default/logs/server1/native_stderr1.log#yourmilagemayvaryifyouchangetheloglocations#note-whenusingjythonyoumustusethestringtrue,seebelow.#wsadminAdminConfig.modify（jvm,verboseModeGarbageCollection,0）#WASX7435W:
Value0isconvertedtoabooleanvalueoffalse.#wsadminAdminConfig.modify（jvm,verboseModeGarbageCollection,1）#WASX7435W:
Value1isconvertedtoabooleanvalueoffalse.#要使用以上脚本，请执行下列操作：
将其放在一个文件中并起一个有用的名字，例如verboseGC_on.jython。
确保wsadmin.sh（或者wsadmin，对于Windows）在您的命令路径中。
在命令提示符下运行wsadmin.sh-langjython-fverboseGC_on.jython。
JVM设置现在您已经配置了冗余GC，您可以开始优化堆的大小。
理想情况下GC周期应该：
发生间隔大于10秒在1至2秒内完成下面的脚本将更改堆的大小。
其目标是使堆足够大，大到GC间隔大于10秒；
而又足够小，小到持续时间仅为1到2秒。
对于每个新的JVM版本，GC算法将会得到改进，所以此优化应该会随着时间的流逝越来越容易。
清单4.native_stderr1.log，其GC间隔6893毫秒，持续时间456毫秒.linesdeleted.GC（14）;
GCcyclestartedTueDec2716;
18;
1320056）,weak89,final88,phantom0清单5.将JVM堆增加到512MB-1GB#（c）copyright2005#samplecode-notsupported#AdminConfig.help（）server1=AdminConfig.getid（/Node:
tux1Node01/Server:
server1/）printserver1jvm=AdminConfig.list（JavaVirtualMachine,server1）printvariablejvmisprintjvmprintAdminConfig.show（jvm）printAdminConfig.show（jvm）printchangejvmsettingsAdminConfig.modify（jvm,initialHeapSize,512,maximumHeapSize,1024）printAdminConfig.show（jvm）printAdminConfig.show（jvm）AdminConfig.save（）连接池设置小型（4个CPU）数据库服务器的“最佳状态”是提供100-200个连接。
WebSphere作为数据库服务器前面的一个连接集线器。
连接池的大小限制了开放多少数据库连接来受理传入的页面请求。
清单6中的脚本将Trade6应用程序中使用的JDBC数据源的数据库连接池限制设置为113。
如果您的应用程序使用所有可用的连接，则大多数连接都可能有一个需求未能满足。
您可以通过阅读javacore来检测此未满足的需求，或者通过增加连接数并查看什么时候应用服务器停止请求更多的连接。
如果连接数等于或大于WebSphere客户端用户数，则应该检查应用程序是否存在不严谨的代码。
清单6.将JDBC连接池大小设置为113#（c）copyright2005#samplecode-notsupportedserver1=AdminConfig.getid（/Node:
server1/）printserver1jvm=AdminConfig.list（JavaVirtualMachine,server1）print-variablejvmisprintjvmprint-AdminConfig.show（jvm）myds=AdminConfig.getid（/DataSource:
TradeDataSource/）mydslist=AdminConfig.list（ConnectionPool,myds）print-before:
printAdminConfig.show（mydslist）AdminConfig.modify（myds,connectionPoolmaxConnections113）AdminConfig.save（）#AdminConfig.modify（myds,connectionPoolminConnections20）#AdminConfig.save（）print-after:
mydslist=AdminConfig.list（ConnectionPool,myds）printAdminConfig.show（mydslist）#monitorconnectionsatthedatabasewiththecommand#watch-d-n5db2listapplications|wc-l#orinformix#watch-d-n5onstat-gses|wc-l#thiswillincludesomeirrelevantlinesincount-feelfreetoegrepthemout启用Servlet缓存WebSphereApplicationServer内置了两个性能工具以帮助改进配置。
PerformanceAdviser会友好地建议您优化servlet缓存，如果您同意，它将使性能得以改善。
下面的图8显示了性能查看器的图形输出。
要访问免费的IBM联机EducationAssistant（它提供了有关如何使用PMI工具的教程），请查阅下面的参考资料。
清单7.启用Servlet缓存server1=AdminConfig.getid（/Node:
server1/）printserver1mywebcont=AdminConfig.list（WebContainer,server1）printAdminConfig.show（mywebcont）printnowmodifysettingsAdminConfig.modify（mywebcont,enableServletCaching,true）AdminConfig.save（）printAdminConfig.show（mywebcont）图8.性能查看器线程池计数此脚本适度地增加线程池以保证CPU能够接受。
一个CPU可以驱动50到75Java线程。
该脚本很重要，因为它必须发现与Web容器相关的线程池。
一些简单的Jython代码发现正确的标识符，然后为活动线程分配新的最小和最大值：
清单8.增加WebContainer的线程池大小server1=AdminConfig.getid（/Node:
server1/）#showallthreadpools#printAdminConfig.list（ThreadPool,server1）#fromalltheThreadPoolstaketheWebContainer#itwilllooksomethinglikethis:
#webpool=WebContainer（cells/tux1Node01Cell/nodes/tux1Node01#cont./servers/server1|server.xml#ThreadPool_1113265230034）#hereishowtofindthethreadpoolwithjython#tpList=AdminConfig.list（ThreadPool,server1）.split（lineSeparator）#nowloopandfindWebContainer#thestring.count（）testsforasubstring#forproductionpleaseaddyourownerrorhandlingfortpintpList:
iftp.count（WebContainer）=1:
tpWebContainer=tp#whitespaceissignificantinjython,sotheun-indentedline#endsthecodeblockprinttpWebContainerprintAdminConfig.show（tpWebContainer）#nowthatwehavetheidentifiertogettotpWebContainer#adjustthesettings#AdminConfig.modify（tpWebContainer,maximumSize,75）AdminConfig.save（）AdminConfig.modify（tpWebContainer,minimumSize,50）AdminConfig.save（）printAdminConfig.show（tpWebContainer）高级优化思想：
下一步优化什么有很多参数可以优化一些可以使系统变得更快，一些则会使之变得更慢。
要阅读优化佳作，请查阅下面的参考资料中的SpecJAppServer2004全面披露报告。
有大量创建脚本的资源相信您会同意使用脚本是最好的方法。
在您通过一两次使用管理GUI了解了可用的参数范围后，将会考虑转为使用脚本。
有关脚本的更多信息，请参阅下面的参考资料。
结束语本文描述了如何基于一些简单的经验来配置WebSphereApplicationServer。
同时让您通过访问下面的许多资源来获得关于性能优化的更多信息。
在实验基准训练中，单一的最大改善是什么？
优化应用程序！
下面的图9显示了Trade6应用程序的配置页面。
切换到直接的数据库访问和JMS是性能改善的最大单一贡献者。
其他应用程序参数也提供了性能改善。
该实验示例允许通过Web页面更改应用程序。
您的应用程序也可以通过配置文件来获得类似的灵活性。
图9.Trade6应用程序配置页面：
单个CPU、0.2秒响应时间如果您达到或超越了性能目标，还应该做些什么呢？
在下面的图10中，拥有0.2秒响应时间，看起来优化已经到头了。
此时，您可以用更多的用户、更大的每用户事务数，或者更复杂的事务来增强测试工具。
对于许多用户数超过计划的情况，详细的性能描述将使您了解配置平台的容纳范围有多大。
您可能对如何羸得实验练习和如何从示例应用程序获得最佳性能感兴趣。
设计该实验和撰写本文的目的不是为了赢得一场竞争，而是为提高WebSphereApplicationServer性能提供一个快速指导。
如果我忽略了您最喜欢的优化参数，我将很乐意在以后的文章中将它包含进来请将您的优化建议用脚本形式发送给我，我的邮箱是。
我期待您反馈您觉得容易优化且优化后能获得很大性能改善的参数，并将代码示例发送给我们。
图10.应用程序优化提供最大收获：
在一个CPU上获得0.2秒响应时间！
升级会员 