这个场景给的信息还是太少了,我做一些不太离谱的假设分析一下,假设是这样的场景对延迟不太敏感,这个是从题主5分钟处理50w数据计算的问题假设的
时序查询返回的数据不大,这个是个经验假设,根据我见过的场景猜的
计算部分是简单的聚合计算,但是同时处理的数据很多,所以用时比较长
首先,这100个线程需要干掉。我目前还没见过CPU物理核在100左右的服务器,用GPU的大佬可以当我没说。
线程数量其实是一个很微妙的调优选项,很多架构的性能最优点会在线程数量比核数稍微大一点的位置上,也有反过来的。有一个简单的评测方法,看看服务的系统态CPU时间占比,100个线程如果放到16核上去跑,系统态时间就海了去了。
其次,我猜测,你的100个线程里面是串行逻辑“网络IO接受request->查数据->计算->网络IO返回结果”,这是浪费资源的做法,用线程池来拆分请求是比较合适的。
典型的拆分原则是按照处理时间和IO比例进行拆分。查询数据的部分可以单独拆开一个线程池,粗略估计可能只需要四五个线程就可以搞定。流程两端的网络IO可以用一个线程池搞定,同样是四五个线程左右。最后计算的部分可以用(核数 - 查询线程数 - 网络IO线程数)来确定线程池大小,毕竟太多线程对计算并没有什么好处。
做完以上异步化拆分,假设没有其他资源瓶颈的情况下,如果后端查询数据的吞吐足够,即便1000条请求不能在1s内处理完,1s中也能处理完1000条请求,这就是流水线,是不是很微妙XD
最后,算消耗。假设以上优化做完之后,一条请求需要时间t,需要内存m,那么至少需要1000t*m这么多的内存。估计你的场景可以水平切分,直接分到多台机器上来摊销内存就好了。至于网卡什么的,慢慢算哪块是短板吧