Tomcat6优化汇总–让R61本本也能跑上两千
前言：
上个星期对平台开发系统进行了首次压测，在晶晶的压力测试帮助下，终于将IBM R61的本本跑出了2100用户的好成绩（Tomcat6+Oracle11g+PlatForm+Ubuntu8.10）！
另，不过细节过程可能忘记了，晶晶表介意，大概吧事实讲述清楚，好不！！：）
楔子：
压力测试，通过对tomcat6的逐步优化，终于让IBM R61压测用户跑上了2100人，有点极限的样子，单在整个测试过程中除了系统cpu资源使用100%之外，硬盘响应几乎为无，测试完成后整个系统保持稳 定，无崩溃迹象，这说明本本局限了在线压力的继续提高（毕竟不是服务器），呵呵，好了，不介绍了，开始讲述，故事正在开始……
第一章 三百已是才能尽，五百哪敢去高攀
初始开始压力测试时，定的目标为3000户在线并发的目标（虽然最后也没有成，但还是比较欣慰的，毕竟是用本本，不是在主业Web服务器上测试）, 作为适应性的第一测试，只将用户压力定在了500。当晶晶同学将压力并发测试系统准备好，并完成第一轮测试时，都绝望了–通过用户数仅仅为280人左右， 晶晶同学告诉我“估计你的本本300用户已经是极限了”。于是，在他的要求下从200开始测试，我无奈的同意了……^>^|||
第二次两百用户的测试非常顺利的通过，各环节耗时除登录耗时占用比例交大外，其余各阶段都非常合格。测试过程中，系统cpu资源只提升了5%不到， 硬盘无消耗，本本上的各项操作也非常正常，无任何延时现象，数据库链接监控发现最大链接数没有突破10。这，这……，这就有点不正常了,压测过程系统过于 平静、清闲了点。开始和“王老五”分析数据库原因，突然一拍脑袋，这正是“机关算尽太聪明、反害了卿卿（R61）性命……”
第二章 王老五随语惊梦人，鱼财主死抠算线程
“老五呀，数据库线程怎么一点点压力都没有，R61也是，整个压测跟玩似的清闲，这很不对劲”，我沮丧的对着王老五说着。王老五撇了我一眼，有转头 紧盯着oracle资源监控系统，然后就是点头和“是呀”的回答。我是有点抓狂了，也跑到王老五的笔记本前看着那些代表数据资源的绿条条，心里就纳闷了， 怎么就不红呢，红了就好了……。正在我想的时候，王老五随口来了句“链接数相当少，线程压力几乎没有嘛”。惊，绝对的惊，出了一脑门子的汗，……
“对，线程，……，嗯，这和哪里关联着呢，到底这扇门通向哪里？？”我不停的想着，考虑着，眼前已经出现了门，我正在不停的拽那个把手，那个门后面应该就是“我所需要的……”
对了，Ajax Web 访问时线程访问频繁，tomcat执行线程为单线程响应方式，数据链接数极低（不到10），说明线程池使用效率也同样低，过多用户多处于等待执行线程的状 态，这也刚好验证了晶晶的测试失败原因–链接超时。那到底是什么导致tomcat线程池使用能力不足呢？这时，我突然想到，Ubuntu系统是一个基于 Linux的系统，一般的系统用户都是被强制受限的，比如，单线程打开文件最大数、用户最大线程数、打开文件最大尺寸、最大内存使用限制……等等。可是普 通Ubuntu用户组用户是不允许使用调整命令“ulimit”；而且Ubuntu的root用户是被锁死的；sudo命令执行，结果是shell中没有 “ulimit”命令(sudo: ulimit: command not found)。
这正是“门前已扫五升雪，瓦上还聚三升霜……”
第三章 鱼头大海捞虾米，布图怯怯启Root
1、创建root用户：
sudo passwd root
注：根据提示设置root用户密码（创建root用户）
2、允许root用户登录
点击 System （系统）-> Preferences（系统管理） -> Login Window（登陆窗口） 菜单，并切换到 Security（安全） 选项页，然后选中其下的“Allow local system administrator login”（允许本地系统管理员登陆）选项。
3、禁用Root用户
sudo passwd -l root
------------------------------------
另类改变方法：
1.设置好root密码！
$ sudo passwd root
2. 屏蔽gdm改用终端登录
$ sudo mv /etc/rc2.d/S13gdm /etc/rc2.d/s13gdm
3. 重启计算机
4. 以root登录并startx可以了！系统怎样改都行了，小心哦！！
5. 恢复gdm方式（如果你的gdm可以正常工作的话）
$ sudo mv /etc/rc2.d/s13gdm /etc/rc2.d/S13gdm
6. 重启计算机！！
这正是“书到用时方恨少，事非经过不知难……”
第四章 调教TOM晶晶叫好，布图吃饱硬盘不保
1、开启Root用户后，使用root用户登录，调整Linux系统限制，如下：
ulimit -n 65533
ulimit -u unlimited
进入tomcat目录，启动：
./catalina.sh run
看着终端的屏幕开是刷，显示出清晰的tomcat6的启动日志
晶晶的压力测试直接500，在未做其余任何调整的情况下通过，其中表单提交过程耗是在12秒左右，稍微慢了点，王老五反应数据库链接数突破到19后停滞，那么继续优化
2、调整platform数据源的线程设置
假设发布目录为Webroot，那么在WebRoot/META-INF/下建立context.xml文件，调整数据源配置
(注：tomcat6才能支持发布目录数据源配置，以前的版本改文件路径在tomcat安装路径下的conf目录中)
context.xml文件内容如下：
<?xml version=”1.0″ encoding=”UTF-8″?>
<Context path= “/WebRoot ” privileged= “true” reloadable=”false”>
<Resource name=”sysDataSource” auth=”Container”
type=”javax.sql.DataSource” maxActive=”5000″ maxIdle=”300″ maxWait=”60000″
logAbandoned=”true” username=”yfjz” password=”password”
driverClassName=”oracle.jdbc.driver.OracleDriver”
url=”jdbc:oracle:thin:@10.10.10.XX:1521:al32″ />
<Resource name=”yfjzDataSource” auth=”Container”
type=”javax.sql.DataSource” maxActive=”4000″ maxIdle=”200″ maxWait=”60000″
logAbandoned=”true” username=”yfjz” password=”password”
driverClassName=”oracle.jdbc.driver.OracleDriver”
url=”jdbc:oracle:thin:@10.10.10.XX:1521:al32″ />
</Context>
（注：再次测试300户时，数据链接监控发现线程上到199，线程已经解禁了）
3、调增tomcat6响应池：
查找tomcat6安装目录下conf目录中的server.xml文件，进行编辑
屏蔽tomcat默认Connector：
<!–
<Connector port=”8080″ protocol=”HTTP/1.1″
connectionTimeout=”20000″
redirectPort=”8443″ />
–>
创建高线程的Connector：
<Connector port=”8080″ redirectPort=”8443″
maxHttpHeaderSize=”8192″ useBodyEncodingForURI=”true”
minProcessors=”100″ maxProcessors=”5000″
maxThreads=”5000″ minSpareThreads=”1000″ maxSpareThreads=”4000″
enableLookups=”false” acceptCount=”3500″
compression=”on” compressionMinSize=”2048″
compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain”
connectionTimeout=”60000″ disableUploadTimeout=”true” debug=”0″ URIEncoding=”UTF-8″/>
（注：加入响应线程数控制，加入压缩传递模式，调整超时设置，屏蔽调试模式）
4、增加tomcat6启动内存：
查找tomcat6安装目录下bin目录中catalina.sh文件，在开始增加如下：
JAVA_OPTS=” -Xms1400m -Xmx1400m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true ”
5、增加oracle响应线程数：
王老五将oracle数据线程响应定为1000,这是测试用的，同时监控oracle链接资源
(想知道这个怎么设置的，认识王老五的就找他聊聊，不认识的就网上找找吧，呵呵)
6、开始压测1000户
晶晶开始测试后，确发现有十来户一直处于等待状态，R61本本cpu资源从96%降到10%以下，硬盘灯狂闪，Desktop系统操作响应减缓
使用硬盘资源检查命令发现，硬盘使用资源为100%，说明硬盘满了，系统在寻找缓存操作，硬盘和内存疯狂交互
这真是“一波刚平一波起，平湖落石浪千层……”
第五章 查硬盘日志累计，斩输出平台生春
通过查找，系统硬盘资源撑爆的原因是tomcat日志和platform日志无限追加的原因，解决办法如下：
1、调整platform日志log4j.properties
将首行的“log4j.rootLogger = DEBUG, A1, A2”改为“log4j.rootLogger = INFO, A1”
（注：很简单吧：-）
2、调整tomcat6的日志输出
将下面内容注释掉：
handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler, 5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
（注：行首加#号就行）
3、晶晶继续压测，结果定在2100多户左右
尾声：
从整个过程来看，PlatForm在抗压性上表现突出，自始至终未出现崩盘情况，所有失败用户的错误提示都为“time-out”，只是登录响应时间占总流程比重稍高，仍续继续调整；该测试可以说改变了我对tomcat的定义，在各项优化做足的情况下，tomcat抗亚能力优秀， 也从未崩盘，只是单线程响应是一直诟病的，反映在当集群用户出现是表单响应时间便长，致使我不得不增大了超时时间（原来定在20秒，后来调整到1分钟）； 系统容载量是一个综合性的过程，在整个压测环节中每一步都十分重要，不能仅仅依靠某一个环节的优化就可以安了，在2100户时，数据库链接超过800线， 系统cpu使用量高达96%，硬盘资源几乎不耗费，这说明2G的内存在处理足够多的事物。
以上是IBM R61 2G内存本压测从200用户到2100用户通过的过程，请需要的人借鉴，也希望多提宝贵意见。
