共计 3208 个字符，预计需要花费 9 分钟才能阅读完成。
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 转载请注明起源
