最开始设计项目的时候，因为考虑到是个人部署使用，不会有特别高的并发，于是没有选择比较复杂的异步框架，而是直接使用同步的Flask+waitress。 

后来设计公共API时偷了个懒，仍然沿用了现有的代码，试图通过暴力堆加waitress线程数以试图提高并发承载能力。 
然而结果不尽如人意，程序仅在10qps左右的并发下，就出现了任务堆积，无法正常处理后续请求。 

问题分析
性能分析可以很明显地看出，瓶颈出在网络IO上。用户请求的元数据没有在数据库中命中时，程序需要从网络API请求。尽管多线程能够实现requests并发，但是requests在线程内是阻塞的。当所有线程都在等待requests时，任务堆积就发生了。 
但是Claude-3.7-sonnet（爱来自cursor，我踏马谢谢你啊）的分析让我大跌眼镜，它分析称requests在等待请求期间会占据GIL，导致其他线程也无法处理请...