对开发服务器作了优化

之前，jboss数据源最大连接是20，最小连接数据是5，在jboss的deploy文件夹下*-xa.xml文件中设置

最大jboss线程数maxThreads是250，等待区线程数acceptcount是100，在jboss的deploy下jboss-web.deployer下的server.xml设置

jboss运行时，有一个等待区与运行区，一个请求会先进入等待区，运行区有空闲时，就进行运行区。然后运行区的连接请求会被cpu调度处理。

maxThreads设置的是运行区的大小，acceptCount设置的是等待区的大小。

虚拟机堆大小3G，年轻代1.5G， perm区256m

每个查询，需要查询到800来条数据。

将preFill设置为true，防止连接风暴：

  preFill参数默认为false，表示，只有在第一次sql请求才做数据连接池的初始化。

  比如，最小数据源连接数为9，最大数据源连接数为10，

  这时，服务器在高峰时期重启，启完后，有10个并发，

 第一个请求过来，这时，jboss要新建9个连接，放往连接池，另外9个并发也各自新建一个连接。

  最后jboss新建数据库连接数为9+9，也就是18个数据库连接。

用jmeter测试，1秒1000个并发，运行2秒，即2秒内2000个并发请求，

结果吞吐量为2.5个每秒。

在测试期间，服务器还出现不能获取jboss数据库连接的情况。

修改后，将jboss数据源最大连接数改为150，最小改为30。

jboss最大线程数改为1000，等待区线程数改为1024

测试结果每秒5.7个吞吐量。

之前每个查询，在小并发下只需1秒左右。在高并发下竟然达到了130几秒。

看了下日志，年轻代垃圾回收，应用被暂停120来秒

Application time: 3.5579710 seconds
2014-01-20T14:10:38.979+0800: 1273.954: [GC 1274.350: [DefNew: 1381823K->80683K(1382400K), 122.3489510 secs] 2671832K->1380353K(2992128K), 122.7490440 secs] [Times: user=0.77 sys=1.84, real=122.73 secs]
Total time for which application threads were stopped: 122.8825830 seconds

之后测试如果查询结果为一个，吞吐量为20个每秒。