我正在使用ApacheJMeter测试一个小型的Flask应用程序，该应用程序执行一些CPU密集型任务。
令人惊讶的是，使用--without-threads运行Flask应用的结果明显好于使用--with-threads运行的结果。
Apache JMeter的一些设置和相应的结果如下：
| 线程数（用户）|循环计数|无线程所用时间（秒）|线程花费的时间（秒）|
| - ------|- ------|- ------|- ------|
| 五个|一千|十四|十七|
| 十个|五百|十四|十八|
| 五个|三千|四十三|五十一|
| 十个|一千五百|四十三|五十六|
我希望，在一个纯粹的CPU绑定任务的情况下，多线程版本应该至少和单线程版本一样快。
就执行实际的CPU任务而言，我希望两个版本的性能相同，但是，就下一个线程的处理速度而言，我希望多线程版本稍有优势，因为Flask已经处理了请求，它只是在等待CPU。
在单线程版本（即--without-threads）中，一次只能处理一个请求，而所有其他请求都在等待Flask处理，换句话说，Flask引入了一定的"服务开销"。
在理想情况下，Flask可以立即为新请求提供服务。换句话说，Flask为HTTP请求提供服务的开销将为0。在这种情况下，我希望单线程和多线程版本的速度相同，因为线程是等待Flask提供服务还是等待访问CPU都没有区别。
我想我的理解是不正确的。我哪里错了？
2条答案
按热度按时间olqngx591#
正如@托马斯所建议的，我使用一个生产就绪的服务器运行了更多的测试，我选择的服务器是gunicorn，因为它很容易用Python 3.9设置。
gunicorn接受与此主题相关的两个命令行参数：
--workers-“处理请求的工作进程数。”默认值为1。--threads-“处理请求的工作线程数。”默认值也是1。将
--workers增加到我的CPU可以处理的程度确实提高了性能，但增加--threads并没有提高性能。此外，用1个线程运行8个工作线程比用4个线程运行8个工作线程得到了更好的结果。所以，我尝试通过休眠半秒来模拟一些I/O。最后，增加线程数量确实提高了性能。
mklgxw1f2#
我的应用程序也是一个CPU绑定的应用程序。我使用gthread模式gunicorn由
--worker-class=gthread和结果比其他模式更好。你可以试试。更多信息：https://medium.com/building-the-system/gunicorn-3-means-of-concurrency-efbb547674b7