统一认证优化过程
Edited By Bruce Bob
统一认证是整个系统的入口，所以，统一认证对于大用户量下的并发处理能力直接关系到其他所有系统的使用。
我这里对统一认证高并发优化过程做一个整理。希望对以后其他的工程的集群不是也能提供一定的借鉴经验。
因为我对统一认证的程序还比较有信心，我们首先直接采用了nginx+tomcat双机集群进行并发300的测试。测试结果惨不忍睹。
然后果断采用单机tomcat先进行测试。主要测试tomcat在linux下并发能力。但是，在linux下测试结果依然惨不忍睹。
在测试的过程中，主要出现以下错误
Action.c(18):Error -26374: The above "not found" error(s) may be explained byheader and body byte counts being 230 and 0, respectively.
Action.c(18):Error -26377: No match found for the requested parameter"PeopleSoftJSessionID3". Check whether the requested boundaries existin the response data. Also, if the data you want to save exceeds 1024 bytes,use web_set_max_html_param_len to increase
the parameter size
Action.c(18):Error -27791: Server "59.73.195.178" has shut down the connectionprematurely
其中，27791和 26377错误非常多。在网上找了相关的解决方案之后，发现，有可能是loadrunner的问题。可能是脚本的自动关联出现了问题。因为我是做开发的，对loadrunner不熟悉，同测试部门的同事讨论之后，测试部的同事对测试的录制脚本进行了更改。然后继续进行测试，测试情况好多了。基本没有再出现这两个错误。测试并发100勉强通过。整个登录流程大约需要4s。
此时虚拟机的配置参数是：
JAVA_OPTS="-Xms256m-Xmx512m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m"
当我们采用并发150进行测试时，完全不能通过。用户数量增加到30左右就开始出错。
之前并发100是没有问题的。但这里怎么到50就出现大量的错误，都是服务器没有响应。后来查看tomcat相关日志，出现的错误时这样的：
java.lang.OutOfMemoryError:unable to create new native thread
凭借以往的经验，直接增大虚拟机内存配置。接着进行测试，结果测试的结果更加不理想，到了30左右就出现问题。
配置如下：
JAVA_OPTS="-Xms600m-Xmx1500m -Xss20m -XX:PermSize=300m -XX:MaxPermSize=600m"
后来进行查询，发现了问题的所在。原来对于一般的内存泄漏导致的堆栈溢出，通常的错误信息主要有以下几种。
1.java.lang.OutOfMemoryError: Java heap space
2.java.lang.OutOfMemoryError: PermGen space
3.java.lang.OutOfMemoryError: Requested array size exceeds VM limit
4.java.lang.OutOfMemoryError: <reason> <stack trace> (Native method)
分析server.log种的日志信息，得知是无法创建本地线程所致的问题。也就是说在压力环境下拥有大量的线程，或者本地内存耗尽时，企图创建新的线程时抛出。而系统能创建的线程数的计算公式如下：
(MaxProcessMemory- JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
MaxProcessMemory指的是一个进程的最大内存
JVMMemoryJVM内存
ReservedOsMemory保留的操作系统内存
ThreadStackSize线程栈的大小
所以，如果配置的虚拟机参数存在，问题。会出现配置的内存越大，所能创建的进程（线程）越少的情况。
再次对tomcat进行优化，配置虚拟机参数如下。：
JAVA_OPTS=-server -Xms1024m -Xmx1024m-XX:PermSize=128M -XX:MaxPermSize=256m -XX:MaxNewSize=256m
问题解决。继续测试并发到100的情况。结果依然不通过，主要错误还是服务器500错误。查看服务器日志，出现的问题是这样的：
严重:Servlet.service() for servlet cas threw exception
java.util.NoSuchElementException: Timeout waitingfor idle object
atorg.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:825)
其实就是从超时等待一个对象。程序里采用池化技术的就是数据库连接池了。查看jdbc.properties文件
jdbc.maxActive=50
jdbc.maxIdle=10
jdbc.maxWait=2000
果然，并发100来测试，而服务器的最大连接才50，那出现从池中取对象时超时的现象也不足为奇了。调整如下：
jdbc.maxActive=100
jdbc.maxIdle=20
测试通过。测试结果如下：
可以看到相比第一次测试结果，性能已经得到大幅的优化。
这个时候，数据库服务器采用的是sqlserver2000.因为系统硬件限制，在进行压力测试的情况下，cpu的使用率达到90%+。所以，数据库在这里应该是系统性能的一个瓶颈。更换将数据库换到一台硬件条件相对好一些的机器上。测试结果稍后给出。