金融其它中间件
提高工作效率 WebSphere调优的感受(收藏)
系统升级到aix下的WebSphere后，速度一直比windows下的要慢，曾经在windows下部署了一个jboss4.2，WebSphere6.1，aix下部署了一个WebSphere6.1做测试。程序一样，三个环境连接同一个数据库（数据库环境是windows2003，sql2005），速度是jboss上最快，大约是windows下的WebSphere6.1的两倍，是aix下的WebSphere6.1的四倍。这着实很让人郁闷。鉴于这种情况，客户请过一次IBM的工程师过来，对小机（P570，aix5.3）和WebSphere进行调优，但基本没有多少提高。后来客户再请IBM的来，IBM再来了一个工程师，在客户现场待了两天。最终在大家的努力下，终于解决了速度问题。使得aix下的WebSphere的速度跟windows下的jboss还快一点了。
简单总结一下这次调优：
1、首先，我们写了一个程序，做10亿次的循环运算，windows下的速度是aix的两倍。来的工程师检查了aix下的WebSphere6.1的基本设置，没发现哪里的设置不合理会影响速度。但发现aix的补丁没打到比较新的，也没打全，以及提出64位的WebSphere会比32位的WebSphere慢一些。所以建议打升级补丁，以及换成32位的WebSphere。于是我们在小机上另外安装了一个32位的WebSphere，然后到ibm的网站上下载was32位的补丁，打完补丁后，发现运算速度还真上来了，估计是升级was的jdk的效果。（以前没对这个升过级）。
2、虽然运算速度上来了，但是访问应用系统中对数据库有复杂查询的程序时，速度还是慢，慢了一半。于是，大家想到，这个跟数据库的链接上出问题了。IBM的工程师提出，会不会是，aix架构跟windows架构有区别的问题（因为数据库是windows下的，WebSphere在aix下）。后来，很快被我们推翻了。我们再次在上面提到的3个环境中做了测试（运行相同的对数据库复杂查询的程序），结果是windows下的WebSphere速度跟aix下的WebSphere速度差不多，而jboss的速度最快，是他们的两倍。这说明不是底层架构的问题，是WebSphere的问题。
3、最后，大家想到会不会WebSphere自带的那个SQL驱动的问题。因为我们的jboss连接数据库用的是jtds驱动。WebSphere是用的它自己自带的驱动。于是我们更换WebSphere下的数据源的驱动，换成jtds（是1.2.4版本的）。（这个时候，我之前做过的一个测试，“如何在WebSphere环境上使用jtds作为数据库驱动”起了作用），很顺利的更换了WebSphere连接数据库的驱动。再一测试，哈哈，大功告成，WebSphere的速度终于上来了。
4、最后，我再到网上下载了was64位的补丁，尝试对原来的那个64位的was进行升级打补丁，然后换数据库驱动，发现速度也快了，跟32位的差不多。
呵呵，到这，终于明白了，一直让人恼火的速度问题出在哪了。第一升级was。特别是升级was的jdk。这样运算速度能提高一倍。第二、换连接SQL数据库的驱动，换成jtds。速度又能翻一倍。最后要说的是，jtds要用1.2.4版本的。这个版本的才能在aix下运行。1.2.1版本的jtds在aix下运行有错。
1.线程池大小没有足够的可用线程用于在合理的时间内完成客户请求。线程池的调优需要对服务器进行小心的调试，以达到堆大小和可用线程数之间一个好的平衡。与所得到的性能相比，JVM往往花费更多的时间管理线程队列，任意增加新的线程数量将对服务器产生不利的影响。
2.JDBC连接池JDBC连接池是性能瓶颈的一个非常常见的来源。等待JDBC连接的线程数越多代表应用客户端等待的时间越长。在以数据库为中心的应用达到负载高峰时，确保有足够的可用连接数是避免该问题的一种好办法。
3.堆大小/垃圾回收：对于WebSphere管理员来说，调优堆大小和管理垃圾回收仍然是一项困难的工作。有很多因素影响着JVM堆大小的调优，包括期望的客户数，WebSphere容器使用的JVM，服务器机器，甚至是服务器的操作系统可用物理内存量。
在应用服务器中，有一些资源配置需要调优，例如bean缓冲，池大小和事务超时；Spotlight能够识别WebSphere服务器中这些地方配置有问题的症状。
简单总结一下这次调优：
1、首先，我们写了一个程序，做10亿次的循环运算，windows下的速度是aix的两倍。来的工程师检查了aix下的WebSphere6.1的基本设置，没发现哪里的设置不合理会影响速度。但发现aix的补丁没打到比较新的，也没打全，以及提出64位的WebSphere会比32位的WebSphere慢一些。所以建议打升级补丁，以及换成32位的WebSphere。于是我们在小机上另外安装了一个32位的WebSphere，然后到ibm的网站上下载was32位的补丁，打完补丁后，发现运算速度还真上来了，估计是升级was的jdk的效果。（以前没对这个升过级）。
2、虽然运算速度上来了，但是访问应用系统中对数据库有复杂查询的程序时，速度还是慢，慢了一半。于是，大家想到，这个跟数据库的链接上出问题了。IBM的工程师提出，会不会是，aix架构跟windows架构有区别的问题（因为数据库是windows下的，WebSphere在aix下）。后来，很快被我们推翻了。我们再次在上面提到的3个环境中做了测试（运行相同的对数据库复杂查询的程序），结果是windows下的WebSphere速度跟aix下的WebSphere速度差不多，而jboss的速度最快，是他们的两倍。这说明不是底层架构的问题，是WebSphere的问题。
3、最后，大家想到会不会WebSphere自带的那个SQL驱动的问题。因为我们的jboss连接数据库用的是jtds驱动。WebSphere是用的它自己自带的驱动。于是我们更换WebSphere下的数据源的驱动，换成jtds（是1.2.4版本的）。（这个时候，我之前做过的一个测试，“如何在WebSphere环境上使用jtds作为数据库驱动”起了作用），很顺利的更换了WebSphere连接数据库的驱动。再一测试，哈哈，大功告成，WebSphere的速度终于上来了。
4、最后，我再到网上下载了was64位的补丁，尝试对原来的那个64位的was进行升级打补丁，然后换数据库驱动，发现速度也快了，跟32位的差不多。
呵呵，到这，终于明白了，一直让人恼火的速度问题出在哪了。第一升级was。特别是升级was的jdk。这样运算速度能提高一倍。第二、换连接SQL数据库的驱动，换成jtds。速度又能翻一倍。最后要说的是，jtds要用1.2.4版本的。这个版本的才能在aix下运行。1.2.1版本的jtds在aix下运行有错。
1.线程池大小没有足够的可用线程用于在合理的时间内完成客户请求。线程池的调优需要对服务器进行小心的调试，以达到堆大小和可用线程数之间一个好的平衡。与所得到的性能相比，JVM往往花费更多的时间管理线程队列，任意增加新的线程数量将对服务器产生不利的影响。
2.JDBC连接池JDBC连接池是性能瓶颈的一个非常常见的来源。等待JDBC连接的线程数越多代表应用客户端等待的时间越长。在以数据库为中心的应用达到负载高峰时，确保有足够的可用连接数是避免该问题的一种好办法。
3.堆大小/垃圾回收：对于WebSphere管理员来说，调优堆大小和管理垃圾回收仍然是一项困难的工作。有很多因素影响着JVM堆大小的调优，包括期望的客户数，WebSphere容器使用的JVM，服务器机器，甚至是服务器的操作系统可用物理内存量。
在应用服务器中，有一些资源配置需要调优，例如bean缓冲，池大小和事务超时；Spotlight能够识别WebSphere服务器中这些地方配置有问题的症状。