1. 涉及到后台性能测试的一些参数：

1.1 修改Jboss应用的最大线程数，以及最大允许连接数：

在/home/jboss-4.2.2.GA/server/default/deploy/jboss-web.deployer/server.xml 路径下(红色部分是要修改的)

建议maxThreads，acceptCount和当前期望的并发量调整为1致，然后，connectionTimeout也可以适当调整为60000默认值

<Connector port="8080" address="${jboss.bind.address}"

maxThreads="250" strategy="ms" maxHttpHeaderSize="8192"

emptySessionPath="true"

enableLookups="false" redirectPort="8443" acceptCount="100"

connectionTimeout="20000" disableUploadTimeout="true"

useBodyEncodingForURI="true"/>

acceptCount: 当所有请求处理线程都在使用时，连入连接请求排队队列的最大长度。当排队到最大长度时，所有接收到的请求到将会被拒绝. 缺省值为10.

connectionTimeout: 表示接到连接请求后，connector等待URI请求的时间（以毫秒为单位）.缺省值为60000 (1分钟)，并发增大以后，请求的响应时间都延长了，这个时间也要跟着增大才可以

查看当前jboss的线程情况可以访问：

http://123.125.17.8/web-console/status

maxThreads: 表示connector创建的请求处理队列的最大值, 它决定了connector能够并发处理的最大请求数. 如果不指定，缺省值为200.

· maxSpareThreads: 表示线程池开始关闭无用的线程之前所能允许的无用线程的最大值. 缺省值为50.

· minSpareThreads: 表示connector启动时创建的请求处理线程的数量. 在运行过程中，connector将会确保有指定数量的空闲线程. 该属性值必须设置成小禹. 缺省值为 4.

具体的其他参数的意义，可参考：

http://read.newbooks.com.cn/info/118572.html

其中maxSpareThreads和minSpareThreads最好设置下,当线程池空闲时，能消灭空闲的线程，这个可以根据当前系统正常访问下的线程值来修改

1.2 修改数据库的最大连接数

应用的数据库联接池数通常应该和并发数一致，要求多少并发就配多少连接池

在/home/jboss-4.2.2.GA/server/default/deploy/aLC-ds.xml 路径下

<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->

<min-pool-size>5</min-pool-size>

<max-pool-size>15</max-pool-size>

</local-tx-datasource>

1.3修改虚拟内存的配置

在/home/jboss-4.2.2.GA/bin/run.conf 路径下：

JAVA_OPTS=" –server -Xms512m –Xmx2048m –Xss128k -XX:PermSize=256m -XX:MaxPermSize=512m

前面一个512为最小虚拟内存，后面一个1024M为最大虚拟内存。

Xss为每创建1个线程默认使用的内存大小，最佳值为128K，具体可见这个帖子：

http://gq913.javaeye.com/blog/171370

http://lib.javaeye.com/blog/70972

可以修改为机器的实际内存大小的90%以下.

在机器允许的情况下，我们可以将最大虚拟内存提高一些，不过虚拟内存和前面的maxthreadcount是成反比的，具体的比例关系大致如下：

JDK1.4

-Xmx750 = 4580 threads.

-Xmx1000 = 3608 threads.

-Xmx1500M = 1663 threads

JDK1.5

-Xmx750M = 1129 threads

-Xmx1000M = 880 threads

-Xmx1500M = 384 threads

-Xmx800M 略等 1100threads

http://www.javaeye.com/topic/13910

-server纯粹是内纯行为, SERVER是不需要关心整个系统内存的

见这个帖子：

http://www.javaeye.com/topic/299988

1.4修改事务超时时间(这个值本次没调整，观察的thread访问时间没有超过目前配置300s的)

配置一次事务最大时间，该参数由客户端可能的（合理的）一次访问服务器反应最大时间 和 服务器端后台线程一次处理事务的最大时间决定。

找到文件 /home/jboss-4.2.2.GA/server/default/conf/jboss-service.xml ，查找以下行：

<attribute name="TransactionTimeout">300</attribute>

这个根据事务测试结果再定，300的单位是s,如果有执行较长的事务，才需要改大该值

1.5修改日志打印级别

在大并发的测试的时候，需要调整日志的打印级别，目前系统还采用的是INFO级的，可以提高到ERROR级的，提高服务器性能

调整打印级别，在

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">

<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>

<param name="Target" value="System.out"/>

<param name="Threshold" value="INFO"/>

<layout class="org.apache.log4j.PatternLayout">

<!-- The default pattern: Date Priority [Category] Message\n -->

<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>

</layout>

</appender>

将INFO修改为ERROR

1.6修改系统同1时间打开的文件数

见帖子 http://www.javaeye.com/topic/65175

ulimit –a

ulimit –n 4096,要改哪个参数就用哪个(这样改好像是改了当前用户下的配置)

要对每个用户都有效，必须修改环境变量，将这个值加入环境变量中,我们在跑５００并发下的搜索时遇到了这个问题

2 应用程序级的调优(hibernate)

2.1 fetch size的调整

针对oracle数据库而言，Fetch Size 是设定JDBC的Statement读取数据的时候每次从数据库中取出的记录条数，一般设置为30、50、100。Oracle数据库的JDBC驱动默认 的Fetch Size=15，设置Fetch Size设置为：30、50，性能会有明显提升，如果继续增大，超出100，性能提升不明显，反而会消耗内存。

即在hibernate配制文件中进行配制：

<property name="hibernateProperties">

<props>

<prop key="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</prop>

<prop key="hibernate.show_sql">false</prop>

<prop key="hibernate.jdbc.fetch_size">50</prop>

<prop key="hibernate.jdbc.batch_size">50</prop>

</props>

</property>

Fetch Size设的越大，读数据库的次数越少，速度越快；Fetch Size越小，读数据库的次数越多，速度越慢。

以下摘自http://www.cjsdn.net/post/view?bid=29&id=66799&sty=1&tpg=6&age=0

Fetch Size 是设定JDBC的Statement读取数据的时候每次从数据库中取出的记录条数。例如一次查询1万条记录，对于Oracle的JDBC驱动来说，是不会 1次性把1万条取出来的，而只会取出Fetch Size条数，当纪录集遍历完了这些记录以后，再去数据库取Fetch Size条数据。因此大大节省了无谓的内存消耗。当然Fetch Size设的越大，读数据库的次数越少，速度越快；Fetch Size越小，读数据库的次数越多，速度越慢。这有点像平时我们写程序写硬盘文件一样，设立一个Buffer，每次写入Buffer，等Buffer满了 以后，一次写入硬盘，道理相同。

Oracle数据库的JDBC驱动默认的Fetch Size=10，是一个非常保守的设定，根据我的测试，当Fetch Size=50的时候，性能会提升1倍之多，当Fetch Size=100，性能还能继续提升20%，Fetch Size继续增大，性能提升的就不显著了。因此我建议使用Oracle的一定要将Fetch Size设到50。

不过并不是所有的数据库都支持Fetch Size特性，例如MySQL就不支持。MySQL就像我上面说的那种最坏的情况，他总是一下就把1万条记录完全取出来，内存消耗会非常非常惊人！这个情况就没有什么好办法了

Batch Size是设定对数据库进行批量删除，批量更新和批量插入的时候的批次大小，有点相当于设置Buffer缓冲区大小的意思。Batch Size越大，批量操作的向数据库发送sql的次数越少，速度就越快。我做的一个测试结果是当Batch Size=0的时候，使用Hibernate对Oracle数据库删除1万条记录需要25秒，Batch Size = 50的时候，删除仅仅需要5秒！！！ 可见有多么大的性能提升！很多人做Hibernate和JDBC的插入性能测试会奇怪的发现Hibernate速度至少是JDBC的两倍，就是因为 Hibernate使用了Batch Insert，而他们写的JDBC没有使用Batch的缘故。以我的经验来看，Oracle数据库 Batch Size = 30 的时候比较合适，50也不错，性能会继续提升，50以上，性能提升的非常微弱，反而消耗内存更加多，就没有必要了。

2.2 数据库索引都已检查，都创建了

3性能调优的分析经验

参考文章：

http://zhijie435.javaeye.com/blog/152607

我分析其中文章中的关注点：

3.1内存

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数高;

可高的全局系统CPU利用率;

内存不够出错(out of memory errors)

当前要监控的点：

换页率

进程是否活动

交换区磁盘活动次数

系统cpu利用率

程序的内存溢出错误

3.2处理器：

CPU资源成为系统性能的瓶颈的征兆:

很慢的响应时间(slow response time)

CPU空闲时间为零(zero percent idle CPU)

过高的用户占用CPU时间(high percent user CPU)

过高的系统占用CPU时间(high percent system CPU)

长时间的有很长的运行进程队列(large run queue size sustained over time)

当前要监控的点：

响应时间

Cpu空闲时间

用户占用cpu的时间

系统占用cpu的时间

当前运行的进程队列

3.3磁盘I/O

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization)

太长的磁盘等待队列(large disk queue length)

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)

太高的物理I/O速率:large physical I/O rate(not sufficient in itself)

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

当前要监控的点：

磁盘利用率

磁盘等待队列

物理i/o速率

缓存命中率

进程运行队列和当前cpu使用率

4目前发现的问题：

压搜索的时候 ，发现瓶颈如下：

a)Fireware处理转发，当并发达到500的时候，转发处理不过来了

b)图片服务器，当并发达到500的时候，会造成过高的链接去访问图片服务器

c)访问搜索的时候，buffalo在加载 左侧类目的时候，好像有内存溢出，反映很慢，一直在Service状态的线程，要考虑，走别的方式替换，比如jquery?

更多干活请关注我的头条号【纯洁的程序员】，绝不让老铁们失望！！！