我有一个机器学习应用程序，该应用程序使用 flask 公开api（对于生产来说，这不是一个好主意，但是即使我将使用 django 以后，这个问题的想法就不会改变。
主要问题是如何为我的应用服务多个请求。几个月前celery已被添加来解决此问题。在celery中产生的工作程序数量等于计算机中存在的核心数量。对于极少数用户来说，这看起来还不错，并且已经投入生产了一段时间。
当并发用户数量增加时，很明显，我们应该对其进行性能测试。事实证明：对于 30 GB 和 8核心计算机，它可以处理20个用户，而无需身份验证，也不需要任何前端。看起来不太好。
我不知道这些东西是什么：应用程序服务器，Web服务器，模型服务器。搜寻此问题时：gunicorn是一个很好的应用程序服务器python应用程序。
gunicorn或任何其他应用程序服务器与celery一起使用，为什么celery并仅将gunicorn与应用程序一起使用，则可以实现并发。我读过某个地方celery对机器学习应用程序不好。gunicorn和celery的用途是什么。我们如何才能做到两者兼得。注意：主要目标是最大化并发性。在生产中服务时，将添加身份验证。一个前端应用程序可能会在生产中的这两个阶段生效。
答案 0 :(得分：4)
烧瓶中没有污物。如果实际上您只需要一个Web API包装器，那么flask可能比django更好（这是因为django很大，而您将仅使用其功能的一小部分） ）。
但是，您的并发问题显然源于您对每个请求都进行了一些繁重的处理这一事实。根本没有办法解决；如果每个请求需要一定数量的计算资源，那么就无法解决这些问题。从现在开始，这是一个杂耍表演。
如果您希望立即得到保证的响应，则需要与潜在的同时请求数量一样多的工作人员。如果您无法在一台服务器上增加足够的资源，则可能涉及在多台服务器上进行负载平衡。 （提示gunicorn，一个Web应用程序服务器，负责接受连接，然后将其分发到多个应用程序进程。）
如果您可以立即得到答复，可以让他们排队。 （提示celery，任务队列，工作进程可以使用该任务队列来检索要完成的下一件事情，并存储结果）。如果您在同一请求-响应周期中不需要响应，则此方法效果最好。例如您从客户那里提交了一份工作，而他们仅得到已收到该工作的确认；您将需要第二个请求来询问作业的状态，以及如果作业完成的话可能的结果。
或者，您可以使用websockets或Tornado代替Flask，以在客户端可用时将响应推送给客户端（与用户轮询结果或等待实时HTTP连接相反）并处理服务器进程）。