不良的Django应用程序降级

Question

我被分配为支持旧的Django应用程序。该应用程序过去曾在gunicorn同步工作者上运行。但是，它变得越来越慢。最近，一名工程师进行了更改，将Gunicorn异步工作者与 gevent 一起使用。

这周，当HTTP请求数量增加时，系统遭受了严重降级。我们在error: can't start new thread上收到了许多gevent.threadpool._add_thread。命中率最高的Django视图在完成之前会执行约400条SQL查询，并呈现一个复杂的模板。

与此新的异步工作程序相比，渲染模板的查询数量和CPU时间的增加是否会不好？如果是这样，我该如何向其他人解释？

连接池配置为不超过postgres连接的限制。

Answer 1

我将其写为答案而不是评论，因为尽管它不能解决您的情况，但从技术上讲确实可以解决您的问题。另外，评论中没有足够的空间来要求所有必要的澄清，以便从一个地方到另一个地方。

  

我被分配为支持旧的Django应用程序。该应用程序过去曾在gunicorn同步工作者上运行。但是，它变得越来越慢。最近，工程师进行了更改，将gunicorn异步工作者与gevent一起使用。

部署方法基本上与Django应用无关，除非编写该应用程序的人所做的事情依赖于同步请求处理。出于某些原因，我将第一步切换回部署方法。

1. “一个旧的Django应用程序”表明它所使用的版本已不受支持。如果是这样，无论如何都不应公开，在这种情况下，流量几乎可以忽略不计。
2. “速度越来越慢”需要解释。如果以某种方式显着影响了响应速度，那么 是您应该从中开始的症状。
3. 无论是从同步切换为异步的人，都应提供其推理并解释其尽职调查，以便您了解他们所做的工作，以确保他们了解自己不会破坏这件事（并且，如果缺少，您可能至少知道不必寻找什么。）

  

这周，当HTTP请求数量增加时，系统遭受了严重降级。我们收到了很多错误：无法在gevent.threadpool._add_thread上启动新线程。命中率最高的Django视图在完成之前会执行约400条SQL查询，并呈现一个复杂的模板。

每页

400个查询指向真正写得不好的代码，或者不太可能的是，很多用户查看的是一个信息丰富的页面，而这些页面根本无法从任何有用的缓存中受益。您在评论中提到了“改善SQL查询”，但是Django的ORM非常适合构建查询，因此希望您只是在一般性地讲；如果构建此文件的人是手工编写SQL并将其传递给ORM，那肯定是另一个潜在的问题。

如果您可以提供有关系统以前处理好的流量以及现在阻塞的流量的信息，将很有用。了解您的部署也很好。自动缩放设置可以缓解这种情况，但是如果您以较低的效率重新配置它也会增加成本，那么这是一个折衷。

  

与此新的异步工作程序相比，渲染模板的查询数量和CPU时间的增加是否会不好？如果是这样，我该如何向其他人解释？

如果仅仅是因为应用程序被请求超载所致，异步部署实际上应该有所帮助（或至少使数据库读取您的瓶颈，但这也是极不可能的，因为您不是从SQLite文件中读取内容软盘）。

  

连接池配置为不超过postgres连接的限制。

如果达到数据库连接限制，您将面临一个完全不同的问题。我认为这是极不可能的。