Question

是否有任何智能方法可以找到业务逻辑中的瓶颈。例如，我们有应用程序，它有一个在大项目中执行HttpResponse（'1'）的视图。我们确信，中间件中不存在任何SQL查询。但HttpResponse工作真的很慢（50 rps vs 200 rps on clear django project）。

可能是什么原因？
在这种情况下如何找到瓶颈？
我们也知道，在明确的项目中，每个请求和我们的项目中用于对象的内存少于1 Mb - 超过2Mb。如何找到这些物体？

Answer 1

调试工具栏效果很好，但我也喜欢运行django-devserver。它可以为您提供比有时处理的更多信息。

DEVSERVER_MODULES = (
    'devserver.modules.sql.SQLRealTimeModule',
    'devserver.modules.sql.SQLSummaryModule',
    'devserver.modules.profile.ProfileSummaryModule',

    # Modules not enabled by default
    'devserver.modules.ajax.AjaxDumpModule',
    #'devserver.modules.profile.MemoryUseModule',
    'devserver.modules.cache.CacheSummaryModule',
    #'devserver.modules.profile.LineProfilerModule',
)

这是我打开的模块，开始后点击管理页面：

Django version 1.3.1, using settings 'myproject.settings' Running django-devserver 0.3.1 Threaded django server is running at http://127.0.0.1:8000/ Quit the server with CTRL-BREAK.
    [sql] SELECT ...
      FROM "auth_message"
      WHERE "auth_message"."user_id" = 1
    [sql] SELECT ...
      FROM "django_admin_log"
      INNER JOIN "auth_user" ON ("django_admin_log"."user_id" = "auth_user"."id")
      LEFT OUTER JOIN "django_content_type" ON ("django_admin_log"."content_typ_id" = "django_content_type"."id")
      WHERE "django_admin_log"."user_id" = 1
      ORDER BY "django_admin_log"."action_time" DESC LIMIT 10
    [sql] 4 queries with 0 duplicates
    [profile] Total time to render was 0.54s
    [cache] 0 calls made with a 100% hit percentage (0 misses) [30/Nov/2011 08:36:34] "GET /admin/ HTTP/1.1" 200 21667 (time: 0.69s; sql: 0ms (4q))
    [sql] SELECT ...
      FROM "django_flatpage"
      INNER JOIN "django_flatpage_sites" ON ("django_flatpage"."id" = "django_fatpage_sites"."flatpage_id")
      WHERE ("django_flatpage"."url" = /favicon.ico/
             AND "django_flatpage_sites"."site_id" = 1)
    [sql] 1 queries with 0 duplicates
    [profile] Total time to render was 0.02s
    [cache] 0 calls made with a 100% hit percentage (0 misses) [30/Nov/2011 08:36:34] "GET /favicon.ico/ HTTP/1.1" 404 2587 (time:
0.89s; sql: 0ms (1q))

Answer 2

我猜你的瓶颈不在你的django代码中。您使用什么Web服务器，以及工作进程处理了多少请求？

如果你使用mod_wsgi，请确保有足够的工作进程，并且最大请求很高。

当然，请确保未设置settings.DEBUG。

Apache日志可以包括请求处理时间（以微秒为单位）：http://httpd.apache.org/docs/current/mod/mod_log_config.html检查％D

检查中间件解释器在+ django代码中的时间。

# Middleware to check how long the request was in the wsgi queue:
class FooMiddleware:
    def process_request(self, request):
        ...
        queue_start=request.META.get('HTTP_X_QUEUE_START', None)
        if queue_start is not None:
            # How long was the request waiting in the wsgi queue?
            # In Apache Config: 
            # RequestHeader add X-Queue-Start "%t" (in <VirtualHost>)
            queue_start = int(queue_start[2:])/1000000.0
            wait_in_queue=time.time()-queue_start
            if wait_in_queue>1:
                logging.error('Request was too long  (%.3fs) in wsgi-queue: %s' % (
                        wait_in_queue, request.build_absolute_uri()))

Answer 3

您可以尝试New Relic，看看它是否有助于缩小问题区域。

好的是，你可以在生产应用程序中使用它，在那里你不能使用Django调试工具栏。

Django的。业务逻辑瓶颈。

3 个答案: