django-CMS 与远程 mysql 数据库的性能

Question

我尝试在 GoogleAppengine 上运行一个 django-CMS (+filer +easy_thumbnails) 和一个远程 mysql 数据库，并带有 cloudstorage。在修复了与文件系统相关的性能问题并修复了 django-google-cloud-storage 模块 (http://github.com/locandy/django-google-cloud-storage) 后，性能仍然非常糟糕（每个请求预缓存 4 秒）。本教程中的大部分内容都被配置为默认设置。

时间是针对通用页面呈现请求（无缓存，未登录，不包括实例启动时间）。最快的是 1.7 秒和 40 个数据库 RPC 的空白页面（无图像，无文本）。最慢的一整页包含许多图像和一些文本，需要 4 秒和 100 次 rdbms.Exec 调用。我使用了 appengine python 分析模块。

平均每个查询需要 45 毫秒。

有没有我们遗漏的配置？

是否有人成功地在云中部署了 CMS，并带有可用的远程数据库？

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.contrib.auth.context_processors.auth',
    'django.contrib.messages.context_processors.messages',
    'django.core.context_processors.i18n',
    'django.core.context_processors.request',
    'django.core.context_processors.media',
    'django.core.context_processors.static',
    'cms.context_processors.media',
    'sekizai.context_processors.sekizai',
)

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
    'cms.middleware.page.CurrentPageMiddleware',
    'cms.middleware.user.CurrentUserMiddleware',
    'cms.middleware.toolbar.ToolbarMiddleware',
    'cms.middleware.language.LanguageCookieMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
)

DATABASES = {
    'default': {
        'ENGINE': 'google.appengine.ext.django.backends.rdbms',

分析：

  (1) 2014-01-15 12:15:03.358 "GET .../benefits/" 200 real=4636ms api=0ms overhead=9ms (89 RPCs, cost=0, billed_ops=[])
  (2) 2014-01-15 12:14:56.862 "GET .../preise/" 200 real=5200ms api=0ms overhead=9ms (94 RPCs, cost=0, billed_ops=[])
  (3) 2014-01-15 12:14:47.673 "GET .../einstieg/" 200 real=4684ms api=0ms overhead=8ms (87 RPCs, cost=0, billed_ops=[])
  (4) 2014-01-15 12:14:01.054 "GET .../moeglichkeiten/" 200 real=5341ms api=0ms overhead=10ms (98 RPCs, cost=0, billed_ops=[])
  (5) 2014-01-15 12:13:31.516 "GET .../werkzeuge/" 200 real=5176ms api=0ms overhead=9ms (96 RPCs, cost=0, billed_ops=[])
  (6) 2014-01-15 12:13:00.507 "GET .../einstieg/" 200 real=5460ms api=0ms overhead=9ms (94 RPCs, cost=0, billed_ops=[])
  (7) 2014-01-15 12:12:59.891 "GET .../" 302 real=369ms api=0ms overhead=0ms (7 RPCs, cost=0, billed_ops=[])

Answer 1

在使用文件管理器和简易缩略图的推荐设置中使用 appstats 分析 django-CMS 并排除 cloudstorage 后，无法使用远程数据库在 500 毫秒内呈现新的未缓存 空 页面.

添加到页面的每个占位符或功能都会添加几个顺序执行查询。一个复杂的页面最多有 100 个查询，一个中等页面大约有 50 个。这增加了一个页面的 4-5 秒渲染时间。

我们在欧洲-美国本地机器上运行了与 SDK 实例的远程数据库连接，这将页面呈现时间增加到 32 秒。访问时间似乎与网络延迟和查询数量成线性关系。

系统仍然可以使用django的数据库缓存，但是管理后台太慢了，不方便使用。结论：django-CMS 不兼容任何云中的远程数据库设置。

作为我们测试的结果，我们修复了一个与 cloudstorage 兼容的未缓存 django 存储模块 http://github.com/locandy/django-google-cloud-storage