WEB性能测试基础之连接池

感谢百度文库：http://wenku.baidu.com/view/458fb0175f0e7cd18425369a.htm
目录    
1  概述...........................................................................................................................................  1
2  Apache 连接池  ..........................................................................................................................  2
2.1  Worker的配置  ..............................................................................................................  3
2.2  Worker 工作过程解析  ..................................................................................................  3
2.3  连接池性能监控  ...........................................................................................................  4
2.3.1  监控配置  ...........................................................................................................  4
2.3.2  Apache 线程概况  ..............................................................................................  4
2.3.3  性能测试考虑  ...................................................................................................  5
2.4  Mod_jk 配置 .................................................................................................................  5
3  Tomcat 中的线程机制  ..............................................................................................................  6
3.1  Tomcat 线程池的实现  ..................................................................................................  6
3.2  Tomcat 线程池的使用  ..................................................................................................  7
3.3  Tomcat 线程池的配置  ..................................................................................................  7
3.4  Tomcat 线程工作概况查看与分析  ..............................................................................  8
3.5  Java 虚拟机工作线程状态查看与分析  .......................................................................  9
3.5.1  与 tomcat manager 的比较  ..............................................................................  9
3.5.2  与 tomcat 日志的结合使用 ...........................................................................  10
4  数据库连接池（C3P0） ........................................................................................................  10
4.1  C3P0 简介 ...................................................................................................................  11
4.2  主要配置参数  .............................................................................................................  11
4.3  与 mysql 数据库的参数配合 .....................................................................................  11
4.4  CRM 系统中的 c3p0 配置 ..........................................................................................  12
4.5  数据库端配置  .............................................................................................................  12
4.6  连接池监控  .................................................................................................................  13
 
1 概述
在性能测试过程中，系统支持的并发数是我们重点关注的指标之一，影响系统所能支持的并
发数的因素非常多，大致说来，有以下几个方面：
  应用程序设计
应用程序的设计是影响系统性能的最关键因素之一，90%的优化，都是通过对应用程序
的优化来进行的，如 sql 效率优化、代码优化等。
  Web 架构设计
Web 系统的架构设计，如 web 服务器集群、数据库机器、数据存储方式等。
  服务器硬件运算能力
主要指 CPU 运算能力、磁盘读写能力等硬件的能力，一般在测试中，这部分往往是很Author: beiyu95 msn:beiyu95@hotmail.com
难更改的。性能优化的目的之一就让应用能够充分发挥硬件的潜力。
  Web 组件的配置
在 web 系统中，我们往往在特定的 web 服务器和数据库服务器之上开发自己的应用。
而 web 服务器和数据库服务器的各种配置会极大的影响我们的性能，同时各种 web 服
务器和数据库服务器的管理与维护、优化等也是一门相对独立的学问。
本文中我们仅对 web 服务和数据库服务器中连接池相关的内容进行探讨，这部分是影响系
统并发数的直接因素之一。
 
线程池作为提高程序处理数据能力的一种方案，应用非常广泛。大量的服务器都或多或少的
使用到了线程池技术，不管是用 Java 还是 C++实现，线程池都有如下的特点：
线程池一般有三个重要参数： 
1.  最大线程数。在程序运行的任何时候，线程数总数都不会超过这个数。如果请求数量超
过最大数时，则会等待其他线程结束后再处理。 
2.  最大共享线程数，即最大空闲线程数。如果当前的空闲线程数超过该值，则多余的线程
会被杀掉。 
3.  最小共享线程数，即最小空闲线程数。如果当前的空闲数小于该值，则一次性创建这个
数量的空闲线程，所以它本身也是一个创建线程的步长。
 
线程池有两个概念： 
1.  Worker 线程。工作线程主要是运行执行代码，有两种状态：空闲状态和运行状态。在空
闲状态时，类似“休眠”，等待任务；处理运行状态时，表示正在运行任务（Runnable）。 
2.  辅助线程。主要负责监控线程池的状态：空闲线程是否超过最大空闲线程数或者小于最
小空闲线程数等。如果不满足要求，就调整之。
接下来我们主要讨论如下几个方面内容：
  Apache 连接池配置与监控
  Tomcat 连接池配置与监控
  Mysql数据库连接池的管理与监控
 
2  Apache 连接池
在 apache 2.0 中，引入了影响性能的最核心模块：MPM（multi‐processing‐modules）,它基于
模块化的设计，设计了多种工作模式，每个工作模式是一个单独的模块。在 apache 编译过
程中，需要指定使用的工作模式，
‐‐with‐mpm=MPM 
Choose the process model for Apache to use. 
MPM={beos|worker|prefork|mpmt_os2| perchild|leader|threadpool}
在 CRM 系统中，使用的是 worker 工作模型。它是全新的支持多线程和多进程混合的工作模
型。使用线程来处理请求，由于使用线程来处理，所以可以处理相对海量的请求，而系统资
源的开销要小于基于进程的服务器。同时，worker 也使用了多进程，每个进程又生成多个
线程，以获得基于进程服务器的稳定性。 Author: beiyu95 msn:beiyu95@hotmail.com
2.1 Worker的配置    
下面是 crm系统中一个典型的 worker 配置，你可以在 httpd.conf 中找到它。（要查看 apache
使用的模块有哪些，可以直接使用 httpd ‐l）
 
<IfModule worker.c>
ThreadLimit      128
StartServers          7
MaxClients           2048
MinSpareThreads      75
MaxSpareThreads      250
ThreadsPerChild      128
ServerLimit          3000
MaxRequestsPerChild   10000
</IfModule>
Apache worker 使用上述配置来管理线程池，提供网络服务。在不同的负载情况，apache 根
据配置的参数来对线程池中的现场进行管理，包括创建新的线程和销毁空闲的线程。
2.2 Worker工作过程解析    
以上述配置为例，我们来分析各个阶段，apache 线程池的状态。
  初始化
在 apache 启动时，会根据 StartServers的值来创建服务进程，此处为 7 个进程。每个进
程中包括的服务线程数为 128。此时需要注意的是，每个进程中都有一个管理线程存在，
因此，实际上每个进程含有 129 个线程。
  连接池管理
Apache 会一直维护一个处于 spare（备用）或 idle 状态的线程组，随时准备服务进来的
请求。这个值是通过 MinSpareThreads 和 MaxSpareThreads 的值来控制这个范围的。当
处于空闲的线程数据超过最小值（此处为 75）时，apache 会创建新的进程，来维持线
程数不小于最小值。同样，当空闲线程数超过最大值时，apache 会 kill 多余的进程，释
放资源，维持线程数不大于最大值。
当系统的负载急剧上升，并发数增加时，apache 可能会创建更多的服务进程来服务增加并
发请求。但是，系统资源是有限的，不能允许 apache 进行无限制的线程创建，否则，反而
会引起系统性能的下降，甚至崩溃。那么是怎么限制 apache 线程数的上限的呢？答案就在
maxclients参数上。
  线程池的限制
  最大线程数
MaxClients限制了 apache实例可以创建的最大线程数，也就是 apache 可以同时服务的
最大并发请求数。
  最大进程数
MaxClients同时也限制了系统最大可创建的进程数：
Max processes=MaxClients/ThreadsPerChild
另外，ServerLimit 也是进程数的一个硬限制，此处为 3000。它必须要大于等于Author: beiyu95 msn:beiyu95@hotmail.com
MaxClients/ThreadsPerChild 的值。
  其他
MaxRequestsPerChild 限制了每个进程可以处理的最大请求数，此处为 10000。当达到这
个值后，该进程将消亡。如果设为 0，该进程将永不消亡。
为什么这么做呢？设计该参数的初衷是为了避免内存泄露。如果存在内存泄露，那么该
进程的消亡将会释放内存，减小影响。
需要注意的是，如果显式声明了 ServerLimit，那么它乘以 ThreadsPerChild 的值必须大于
等于 MaxClients，而且 MaxClients 必须是 ThreadsPerChild 的整数倍，否则 Apache 将会
自动调节到一个相应值（可能是个非期望值）。
2.3 连接池性能监控    
在性能测试过程中，我们可以通过对 apache 连接池线程状态的监控来了解它的使用情况（利
用率），进而分析 apache的负载特征。
2.3.1 监控配置
在打开 apache 的监控，详细方法如下：
To Enable the Server Status, follow the steps given below: 
1.  In  Apache's  httpd.conf  file,  locate  "Location  /server‐status"  tag.  If  you  are  not  able  to
locate the server‐status tag, do the following
2.  Remove  the  comment  in  the  Location/Server‐status  tag,  to  Enable  SetHandler
server‐status
3.Change the attribute "deny from all" to "Allow from all"
4. Remove the comment in "LoadModule status_module modules/mod_status.so".
5. Save the conf file and restart the Apache Server
 
2.3.2 Apache线程概况
打开 apache状态监控后，就可以通过浏览器来查看 apache的状态了，下面是一个典型输出
的概要部分。其中可以查看当前 busy 的线程数和处于 idle 的线程数。
http://site:port/server‐status
 
 Author: beiyu95 msn:beiyu95@hotmail.com
2.3.3 性能测试考虑
通过对 IDLE线程数和 busy 线程数的值进行查看，可以帮助我们更好的了解性能测试过程中
apache 的状态。主要包括：
  Busy 线程数和当前用户数的关系
在性能测试中，一定数量的并发用户进行并发业务操作时，会同时向 apache 提交大量
的请求。这个并发请求中可能包含了静态资源的请求，也可能包含了动态的请求。这时，
我们通过观察一段时间内 apahce busy 线程数和并发业务操作的关系，可以对该场景的
性能从 apache 层面做出判断。
  Busy 线程数和系统负载的关系
系统负载是由多个指标体系的，apache busy 线程数也是其中之一。虽然，apache 以其
良好的性能往往被性能测试人员所忽视，但要对系统的负载分布、负载特点及资源瓶颈
等做出较好的判断，apache  busy 线程数确实是重要的参考指标之一。如果不对此给予
关注，一些因为配置不当等原因造成的性能问题可能会被忽略，造成严重的问题。
  Apache Busy 线程数和 Tomcat busy 线程数的关系
在实际的商业应用系统（如 CRM）中， apache 往往是和 tomcat来配合工作的，由 apache
负责静态资源的处理，而 tomcat 用来处理商业逻辑等应用。在实际应用中，apache 可
以使用 mod jk 来实现和 tomcat 的协同工作甚至负载均衡。
Apache busy 线程数和 tomcat busy 线程数之间的关系，往往反映了系统静态负载和商业
逻辑等动态应用负载的比例关系。从他们的关系上，我们甚至可以结合其他的指标，来
对系统的容量做出估计。
在下一节中，我们将对 tomcat 线程相关话题进行深入探讨。
2.4 Mod_jk配置    
在 Apache 的 httpd.conf 中可以看到 apache 和 tomcat 协同工作使用的配置文件，
 
LoadModule     jk_module   modules/mod_jk.so
Include /home/work/local_hunter/apache/conf/mod_jk.conf
 
配置项中指明了使用 mod_jk.conf 中的配置来与 tomcat 协同工作，在 mod_jk.conf 中，处理
使用 JkMount 来指定 apache 向 tomcat 转发的内容外，同时指明了另一个重要的配置文件
workers.properties。
 
JkWorkersFile /home/work/local_hunter/apache/conf/workers.properties
 
如果使用了 apache+tomcat 集群方式工作，tomcat 集群的配置也是在 worker.properties 中进
行指定的。使用 tomcat集群进行负载均衡是一个专门的话题，在此处我们不进行讨论。
下面是 apache 和一台 tomcat 服务器协同工作时的典型配置：
worker.list=ajp13w,wlb,jkstatus
worker.ajp13w.type=ajp13
worker.ajp13w.host=localhost
worker.ajp13w.port=8009 Author: beiyu95 msn:beiyu95@hotmail.com
worker.ajp13w.connection_pool_size=128
worker.ajp13w.connection_pool_timeout=90000
worker.ajp13w.socket_keepalive=true
worker.ajp13w.socket_timeout=300
worker.wlb.type=lb
worker.wlb.balance_workers=ajp13w
worker.jkstatus.type=status
值得注意的是 connnection_pool_size 这个参数，限制了 apache 子进程可以创建的线程数。
它实际上是创建了一个连接到 AJP 后端的连接池。通常情况下，这个值和 apache 连接池的
ThreadsPerChild 一致就可以了。如果这个值不设置，JK 将自动读取配置，设置为和
ThreadsPerChild 一致。
另外，当 apache 工作在 prework 模式下的时候，不能使用此选项。
 
 
3  Tomcat中的线程机制
TOMCAT的两种线程池方案：
1） APR 的 Pool 技术，使用了 JNI；
2） 使用 JAVA实现的 thradpool；
在 crm 系统中，使用的是第二种，我们接下来对此进行介绍
 
3.1 Tomcat 线程池的实现    
ThreadPool 默认创建了 5 个线程，保存在一个 200 维的线程数组中，创建时就启动了这些线
程，当然在没有请求时，它们都处理“等待”状态（其实就是一个 while 循环，不停的等待
notify）。如果有请求时，空闲线程会被唤醒执行用户的请求。
 
具体的请求过程是：服务启动时，创建一个一维线程数组（maxThread＝200 个），并创建空
闲线程(minSpareThreads＝5 个)随时等待用户请求。  当有用户请求时，调用
threadpool.runIt(ThreadPoolRunnable)方法，将一个需要执行的实例传给 ThreadPool 中。其中
用户需要执行的实例必须实现ThreadPoolRunnable接口。   ThreadPool  首先查找空闲的线程，
如果有则用它运行要执行 ThreadPoolRunnable；如果没有空闲线程并且没有超过
maxThreads，就一次性创建  minSpareThreads 个空闲线程；如果已经超过了 maxThreads了，
就等待空闲线程了。总之，要找到空闲的线程，以便用它执行实例。找到后，将该线程从线
程数组中移走。  接着唤醒已经找到的空闲线程，用它运行执行实例（ThreadPoolRunnable）。  
运行完 ThreadPoolRunnable 后，就将该线程重新放到线程数组中，作为空闲线程供后续使用。  Author: beiyu95 msn:beiyu95@hotmail.com
3.2 Tomcat 线程池的使用    
Tomcat 有两种 EndPoint，分别是 AprEndpoint 和 PoolTcpEndpoint，此处我们只关注后者。
首先， PoolTcpEndpoint 创建了一个 ThreadPoolRunnable 实例——
LeaderFollowerWorkerThread，实际上该实例就是接收（Accept）并处理（Process）用户 socket
请求的 listener。接着将该实例放进 ThreadPool 中并运行，此时就可以接收用户的请求了。
Class: PoolTcpEndPoint
ThreadPool tp;
public  void startEndpoint() throws IOException, InstantiationException {
        if (!initialized) {
            initEndpoint();    }
        if (lf) {
            tp.start();        }
        running = true;
        paused = false;
        if (lf) {
            listener = new LeaderFollowerWorkerThread(this);
            tp.runIt(listener);
        } else {
            maxThreads = getMaxThreads();
            threadStart();
        }
 
当有 Socket 请求时，LeaderFollowerWorkerThread 首先获得了 Socket 实例，注意此时
LeaderFollowerWorkerThread 并没有急着处理该 Socket，而是在响应 Socket 消息前，再次将
LeaderFollowerWorkerThread 放进 ThreadPool 中，从而它（当然是另外一个线程了）可以继
续处理其他用户的 Socket 请求；接着，拥有 Socket 的 LeaderFollowerWorkerThread再来处理
该用户的 Socket 请求。
整个过程与传统的处理用户 Socket 请求是不同的，也和 Tomcat 老版本不同。传统的处理方
法是：有一个后台运行的监听线程负责统一处理接收（注意只是“接收”）Socket 请求，当
有新的 Socket 请求时，将它赋值给一个 Worker 线程（通常是唤醒该线程），并有后者处理
Socket请求，监听线程继续等待其他Socket请求。所以整个过程中有一个从Listener到Worker
切换的过程。
而新版本 Tomcat（6.x）很有创造性的使用了另外一种方法，正如前文所描述的，接收和处
理某个用户 Socket 请求的始终是由一个线程全程负责，没有切换到其他线程处理。
3.3 Tomcat 线程池的配置    
TOMCAT 的线程管理机制较为复杂，不同类型的进程/线程担负着不同的角色。此处我们研
究的是和 web 服务紧密相关的两类连接池：
这两类连接池分别对应的是 http connector 和 web  server connector(AJP)。Http Connector 使
tomcat 可以作为一个独立的 web 服务器存在，满足静态资源的请求服务和动态资源的请求
服务。Web  server  connector 将 tomcat和 apache、IIS等外部 web 服务器连接起来。他们在Author: beiyu95 msn:beiyu95@hotmail.com
tomcat 体系结构中的位置如图所示：
 
事实上，这两类 connector管理连接池的方式和 apache 管理连接池的方式是类似的，此处不
再连接池的管理做赘述。下面给出了两个典型的配置。
HTTP Connector:
 
AJP Connector:
 
结合 2.4 小节中我们看到的 mod  jk 配置的 port 号，我们就不难明白 tomcat 和 apache 直接
的通信机制了。也就是他们是通过 AJP协议在 8009 端口上进行通信的。
3.4 Tomcat 线程工作概况查看与分析    
Tomcat manager 是 tomcat 自带的一个不错的管理工具。我们可以使用它来监控 tomcat实例
的工作状态：
  应用程序列表与状态查看
  虚拟机状态查看
  线程概要信息、工作信息
在 manager 线程池状态信息中，提供了当前系统中本连接池创建的线程总数(current
thread count)和 busy 线程数(current thread busy)。 Author: beiyu95 msn:beiyu95@hotmail.com
 
3.5  Java虚拟机工作线程状态查看与分析    
JCONSOLE是 JDK 自带的一款优秀的 JVM 状态查看工具，可以对 JVM 内部的内存使用情况、
线程使用情况、类使用情况进行健康。并且可以使用 MBEAN 对 JVM 进行管理和调整。此处
我们只关注和线程相关的信息。
3.5.1 与 tomcat manager 的比较
Tomcat manager 给出了线程整体的 busy/idle 信息及连接信息，包括发送的 HTTP请求。可以
让我们明确的得到整个线程池的利用率，以及每个 busy 线程正在处理的请求。
而 Jconsole 则从更底层的角度给了我们 tomcat 中每个线程的信息，它给出了每个线程的状
态（NEW/RUNNABLE/WAITING/TIME_WAITING/BLOCK/TERMINATE） ，以及线程堆栈的追踪信
息。如下图所示： Author: beiyu95 msn:beiyu95@hotmail.com
 
Jconsole 提供的线程信息在进行性能问题定位时将显得特别重要，通过对线程堆栈的追踪，
我们可以找到出现问题的包、类甚至方法。而且，在 JDK 6之后的 jconsole 版本提供了“检
测死锁”的功能，可以直接来检查出发生死锁的线程。
3.5.2 与 tomcat日志的结合使用
下面是默认格式的 tomcat 日志，
[INFO]   2009‐05‐07 17:32:40,707 [ Thread‐172]     scheduling.quartz.SchedulerFactoryBean 
(SchedulerFactoryBean.java:988)       ‐Shutting down Quartz Scheduler
[INFO]   2009‐05‐07 17:32:40,708 [Thread‐172]     quartz.core.QuartzScheduler      (QuartzScheduler.java:542)     
‐Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutting down.
[INFO]   2009‐05‐07 17:32:40,710 [Thread‐172]     quartz.core.QuartzScheduler      (QuartzScheduler.java:470)     
‐Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED paused. 
从日志格式可以看出，tomcat 会打印出当前的线程号。这个线程号就是我们使用 jconsole
进行追踪的线程号。
这样，当从日志中找到出现问题的进程号时，就可以直接使用 jconsole 对进程堆栈进行跟踪
分析了。
4 数据库连接池（C3P0）
 Author: beiyu95 msn:beiyu95@hotmail.com
4.1 C3P0 简介    
C3P0 是一个开放源代码的 JDBC 连接池，它在 lib 目录中与 Hibernate 一起发布,包
括了实现 jdbc3 和 jdbc2 扩展规范说明的 Connection  和 Statement  池的
DataSources  对象。
4.2 主要配置参数    
  acquireIncrement
缺省值：3。当连接耗尽的时候 C3P0一次同时获取的连接数。
  maxPoolSize
缺省值：15。C3P0 维护的连接池的最大值。
  minPoolSize
缺省值：3。C3P0 维护的连接池的最小值。
  initialPoolSize
缺省值：3。初始化时获取的连接数，应该在 minPoolSize与 maxPoolSize之间。
  maxIdleTime
缺省值：0。连接最大的空闲时间，空闲时间超过这个值，连接将被丢弃。如果值为0，永不丢弃。
  idleConnectionTestPeriod
缺省值：0。C3P0进行空闲测试的时间间隔。
在使用这个值时，注意将空闲测试的时间间隔设置要小于数据库空闲连接测试周期，否则，可能会出
现数据库端连接关闭，而C3P0在不知道的情况下仍然将该连接分配给应用的情况，导致异常错误。  
  numHelperThreads
C3P0 是异步操作的。运行较慢的 JDBC 操作通常是通过 helper 线程来执行的，该 helper
线程不能持有竞争锁资源。通过提高这个值一般可以获得较大的性能提升。
4.3 与 mysql 数据库的参数配合    
MySQL 参数 wait_timeout 与 C3P0 参数 idleConnectionTestPeriod、maxIdleTime 如果配合不
当会导致不必要性能消耗。
建议配置：
  设置 idleConnectionTestPeriod 参数时， 需保证 idleConnectionTestPeriod 的设置小于
wait_timeout 的设置，否则空闲连接无法有效保持，后台可能会在进行空闲测试的时
候报警；
  没有设置 idleConnectionTestPeriod 参数时，C3P0 将不进行空闲连接测试，此时要保
证 maxIdleTime 的设置小于 wait_timeout 的设置，否则在前端使用连接时可能会得到
无效连接。
注：本小节结论来自 OP的一份性能测试报告，作者不详。 Author: beiyu95 msn:beiyu95@hotmail.com
4.4 CRM 系统中的 c3p0 配置    
在 applicationContext‐hibernate.xml 文件中，我们可以看到如下配置：
 
从上述配置文件中可以看出，C3P0 的主要配置参数 maxPoolSize、minPoolSize、
idleConnectionTestPeriod、maxIdleTime 都是在外部定义的，此定义在 jdbc‐mysql.properties
中可以找到：
 
这是一个典型的功能功能环境总的配置，实际系统中 maxPoolSize 的大小要根据实际的峰值
并发数来决定。
4.5 数据库端配置    
除了 c3p0 连接池的配置，数据库端进行的配置也对连接属性有着重要的影响。主要参数如
下：
  Max_connections
Mysql允许的最大连接数。这个参数可以在启动时的配置文件中指定，也可以在运行过
程中进行动态调整。
  Max_user_connections
允许单一用户打开的最大连接数。默认值为 0，即不限制单一用户打开的最大连接数。
  Thread_cache_size Author: beiyu95 msn:beiyu95@hotmail.com
设置多少连接放在 cache中，以备重用。这个值可以再运行过程中进行动态调整。
  Wait_timeout
对于不活动的连接，服务器在等待 wait_timeout秒后将其关闭。
4.6 连接池监控    
我们可以通过 mysql status variables 来查看 mysql 连接池的状态（show status like ‘thread%’），
主要有如下几个参数。
  Threads_cached
在 thread cache 中的线程数。
  Threads_created
已创建的线程数。
  Threads_connected
当前打开的连接数。
  Threads_running
处于非 sleeping状态的线程数。
 
在性能测试中，各个连接池都不是孤立存在的，相互之间会相互影响，综合分析他们的性能
特征，结合系统的其他状态参数，才能真正的掌握系统的运行状态，对系统的性能表现作出
准确的判断。
5 案例
5.1 问题表现    
在压力测试过程中，tomcat 的 busy 线程数无法超过 20。即同时处理的请求数不超过 20，
apache 端日志会出现 503 错误，mod jk 日志中会出现“can't find free endpoint”错误。
5.2 定位方法    
1.  使用 tomcat manager 观察 tomcat 线程数发现，busy 线程数不能超过 20.
2.  初步判定应该是配置参数的问题，打开 mod_jk配置问题，发现 cache size 的值设为 20.
3.  查阅此参数的说明，worker.properties 文件中的 worker.worker1.cachesize=xx 和
worker.worker1.cache_timeout=xx 两个选项在 apache  1.2.16 之后的版本已经废弃，但如
果使用将仍然生效。当大用户量时，apache 的 mod  jk 维持的连接数不会超过 cachesize
值，否则将抛出错误，反映在 apache 端，为 503错误。
5.3 小结    
此案例的难点在于了解 tomcat 的线程池工作状态，如果不了解 tomcat 线程池状态，Author: beiyu95 msn:beiyu95@hotmail.com
或者对 mod jk 相关配置了解不透彻，将很难定位到问题的真正原因。而 tomcat manager的
长处正是观察整个线程池的工作状态，这也是它比 jconsole 更适合观察线程池的原因。
此案例也同时说明了，在性能测试中，仅仅观察系统级资源是不够的。在性能测试过程中，
既需要我们了解整个系统工作的 big picture，同时需要我们关注各个组件的工作细节。