1.简介
JSF业务线程池应用JDK的线程池技术，缺省状况下采纳Cached模式（外围线程数20，最大线程数200）。此外，还提供了Fixed固定线程大小的模式，两种模式均可设置申请队列大小。
本文旨在通过一个简化场景（“单服务利用”）下的负载测试，为“JSF业务线程池大小配置”提供基准测试后果，并造成一些广泛实用的论断。
本文的指标读者包含须要合理配置JSF线程大小的压测工程师、开发部署运维工程师以及架构师。本文不波及JSF服务端的其余配置项，也不针对“复合服务利用”的合理配置进行探讨。你能够利用本文提供的论断，作为设计压测用例或评估业务线程池大小的根本办法的参考，以便在实践中合理配置JSF业务线程池大小。须要留神的是，JSF业务线程池大小的合理配置应该基于高保真的负载测试后果。
“单服务利用”指利用仅蕴含一个提供接口，且接口中仅有一个办法。
“复合服务利用”则指利用蕴含多个提供接口或一个接口中含有多个办法。
2.测试用例阐明
本次基准测试选取了USF3.0权限零碎，将其定制化为一个繁多的服务提供者，仅对该提供者的一个办法进行了测试，因而能够看作是一个“单服务利用”。测试中将CPU作为基准测试的外围资源，并思考到JVM垃圾收集器的影响，采纳了简略的测试数据以保障服务每次调用的一致性，并确保YGC具备规律性（即固定调用量会导致一次30+ms的YGC），无FGC的影响。
测试用例的设计中，所有依赖的服务资源都无限度，以确保测试过程中服务的可用率达到100%。咱们的要害性能指标是TP99，即服务响应时长的99%必须小于10ms。
为了测试不同线程池模式下的性能体现，咱们应用了JSF线程池的Cached和Fixed两种模式，并针对每种模式进行了多组测试，以得出在满足TP99<10ms的前提下，零碎最大的负载状况。
测试利用：USF3.0权限零碎(定制化解决)
测试服务：com.jd.susf.service.api.SusfPermissionService#findUserInfo，依据用户信息从Redis中查问一条数据返回的服务。
硬件配置：单台4C 8G
测试方法：在Forcebot零碎采纳了阶梯发压的形式对JSF业务线程池在Cached和Fixed模式下进行了零碎负载测试
拟定SLA要求：服务响应时长的TP99<10ms
注：咱们对USF3.0权限零碎进行了定制，调整了服务提供方的配置数据，仅保留了 com.jd.susf.service.api.SusfPermissionService。
3.测试后果及剖析
3.1.cached线程池的零碎负载
图：JSF默认线程池(cached, threads=200)在不同并发用户数(1-200)下的零碎负载图
| 并发用户数 | TP99 | 吞吐量TPS | CPU利用率(%) |
|---|---|---|---|
| 1~23 | <8ms | 线性增长 | 线性增长 |
| 24 | 8ms | 6553 | 99.62 |
| 25 | 11ms | 6607 | 99.83 |
| 26～79 | 迅速增长 | 迟缓增长 | 99+ |
| 80 | 74ms | 6928 | 99.82 |
| 81~199 | 迟缓减少 | 迟缓降落 | 99.82 |
| 200 | 99ms | 6230 | 99.94 |
小结：默认的JSF线程池配置存在很大的危险。零碎最大可反对24个并发，超过24个并发SLA就无奈满足。
3.2 fixed线程池(队列)的零碎负载
图：JSF固定线程池(fixed+队列)在不同并发用户数(1-50)下的零碎负载图
| JSF业务线程数 | 可反对的最大并发用户数 | TP值(50/90/99/999) | 吞吐量(TPS) | CPU最大利用率（%） |
|---|---|---|---|---|
| 4 | 11 | 7/8/10/18 | 1531 | 27.67 |
| 8 | 25 | 8/8/10/18 | 3113 | 46.45 |
| 16 | 50 | 8/8/10/21 | 6228 | 87.97 |
| 20 | 23 | 3/4/10/15 | 6409 | 99.92 |
| 24 | 22 | 3/4/7/15 | 6178 | 99.86 |
| 25 | 22 | 3/4/6/15 | 6182 | 98.83 |
表：JSF固定业务线程池(fixed+队列)在满足TP99<10ms的零碎最大负载（最大并发用户数）
小结：
① 在fixed线程模式下，CPU的利用率存在应用下限。
② 队列的应用能够无效减少系统对并发量的反对，同时也会带来吞吐量的晋升。然而，因为工作在队列中期待，服务的响应工夫会呈现“水涨船高”的景象，存在肯定危险。
3.3 fixed线程池的零碎负载
图：JSF固定线程池(fixed)模式下，零碎最大并发用户数时的零碎负载
| JSF业务线程数 | 并发用户数 | TP99 | 吞吐量(TPS) | CPU最大利用率（%） |
|---|---|---|---|---|
| 4 | 4 | 5 | 1063 | 20.26 |
| 8 | 8 | 5 | 2216 | 36.62 |
| 16 | 16 | 6 | 4262 | 68.56 |
| 20 | 20 | 5 | 5550 | 86.22 |
| 24 | 24 | 8 | 6711 | 99.62 |
| 25 | 25 | 16 | 6644 | 98.77 |
| 26 | 26 | 19 | 6744 | 99.93 |
小结：综合固定线程池(fixed)的性能体现，须要设置一个正当的线程数大小来均衡CPU资源的充分利用和满足SLA的需要，线程数过小会导致CPU资源节约，线程数过大则无奈满足SLA
4.论断
依据测试后果和数据分析，咱们得出以下论断：
- JSF线程池的默认配置在并发量高的场景下存在危险：所有线上生产环境中的JSF服务所在的服务器，很少有可能在200个线程的状况下还可能满足SLA的。最大200个线程的线程池配置，将服务器置于“并发量高的场景下被压垮”的危险中。线程池大小的合理配置应该来自高保真的负载测试。
- 足量的线程数能力保障资源(CPU)的利用率：业务型的服务通常都存在肯定的IO操作（网络，磁盘等），线程执行过程中会产生期待，CPU利用率不高，须要减少并发的线程数量，让更多的线程参加CPU的调配，能力进步CPU的利用率。服务中IO操作越多，期待时长越长，须要的并发线程就越多。对于有IO操作的业务型服务，负载测试的线程数能够从2N（N是服务器的CPU核数）开始。
- 过多的线程数只会升高零碎的SLA：当线程数已能100%利用CPU后，减少线程数，线程就无奈获取足够的CPU调配，这样服务的响应工夫就会增大。在肯定范畴内，TP99还可能满足SLA的要求，零碎的吞吐量也会有大量的减少。再继续减少线程数，TP99就无奈满足零碎的要求，零碎的吞吐量也会开始降落。
- 固定的线程数能够爱护零碎须要承当的负载能力：固定线程数能够保证系统对CPU的利用率限定在肯定的负载范畴内，爱护零碎稳固运行，保障响应工夫TP99，但也限定了零碎的并发能力。正当设置队列大小能够减少零碎的并发度，也不会影响零碎TP99，但会整体拉高服务的响应工夫，呈现不稳定性的变动，存在危险。
- 让CPU100%的高负载运行：通常服务对外的SLA承诺通常高于服务实在的性能，这是因为咱们思考了基础设施及依赖服务的不稳定性。因而，即便CPU曾经达到了100%，咱们依然能够减少肯定数量的线程数，而不会影响对外的响应工夫TP99的承诺。这样能够进步零碎的并发能力。尽管零碎能够在高负载下运行，但咱们须要进一步进行稳定性测试，以进步零碎的可靠性。
综上所述，线程池大小的合理配置须要联合业务需要和系统资源状况进行评估和测试，并预留正当的buffer空间，以保证系统稳固运行和满足用户的SLA。
5.附录
附录一：统计指标及术语阐明
并发用户数：同时发动申请的用户数。
TP值(50/90/99/999)：客户端的TP值，单位ms，数据来源于Forcebot。
吞吐量TPS：数据来源于Forcebot。
CPU利用率(%)：数据来源于PFinder。
JSF业务线程数：JSF业务线程池的线程数，如：<jsf:server id="jsf" protocol="jsf" threadpool="fixed" _threads_="16" />
fixed/cached：JSF业务线程池的线程池类型，如：<jsf:server id="jsf" protocol="jsf" threadpool="fixed" threads="200"/>
作者：京东物流 刘江波
起源：京东云开发者社区 自猿其说Tech 转载请注明起源