google-app-engine - Django CMS与远程 mysql DB的性能

  显示原文与译文双语对照的内容

我曾尝试在GoogleAppengine上运行一个带有远程 mysql DB的django cms ( +filer +easy_thumbnails ),带有 cloudstorage 。 修复 文件系统 相关性能问题和fork修复django-google-cloud-storage模块( http://github.com/locandy/django-google-cloud-storage ) 后,性能仍然超越了糟糕的( 4s 个请求预缓存) 。 大多数情况下,从教程中配置为默认。

时间用于一般页面呈现请求( 。没有高速缓存,没有登录,不包括实例启动时间) 。 最快的是带有 1.7秒和 40数据库rpc的空页( 。没有图像,没有文本) 。 在 4秒和 100 rdbms.Exec 调用中,包含许多图像和一些文本的页面的。 我使用了 appengine python 分析模块。

平均为 45ms 个查询的平均值。

我们错过的任何配置

在云环境中,任何人都能成功地使用远程数据库部署一个 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=[])

时间: 作者:

通过在建议设置中使用appstats和简单缩略图,并在不包含cloudstorage的情况下,在不使用的情况下,不可能将新的未缓存的页面添加到 less 。

添加到页面的每个占位符或者特性添加几个按顺序执行的查询。 一个复杂的页面最多有 100个查询和一个关于 50的页面。 这将增加 4 -5秒的页面呈现时间。

我们已经在本地机器上运行了一个远程数据库连接,它将页面呈现时间增加到 32秒。 访问时间似乎与网络延迟和查询数量呈线性关系。

系统仍可以用于 Django 缓存数据库,但管理后端太慢,无法方便地使用。 结论:django cms与任何云中的远程数据库设置不兼容。

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

作者:
...