谈谈JSF业务线程池的大小配置 | 京东物流技术团队

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权限系统进行了定制，调整了服务提供方