django-CMS与远程mysql数据库的性能 [英] Performance of django-CMS with remote mysql DB

问题描述

我试图在GoogleAppengine上用远程mysql数据库运行django-CMS（+ filer + easy_thumbnails），并使用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毫秒。

是否有我们错过的配置？ b
$ b

有没有人成功地在远程数据库中使用可在云中部署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.358GET ... / benefits /200 real = 4636ms api = 0ms overhead = 9ms（89 RPCs，cost = 0，billed_ops = []）
（2）2 014-01-15 12：14：56.862GET ... / preise /200 real = 5200ms api = 0ms overhead = 9ms（94 RPC，cost = 0，billed_ops = []）
（3）2014 -01-15 12：14：47.673GET ... / einstieg /200 real = 4684ms api = 0ms overhead = 8ms（87 RPC，cost = 0，billed_ops = []）
（4） 01-15 12：14：01.054GET ... / moeglichkeiten /200 real = 5341ms api = 0ms overhead = 10ms（98 RPC，cost = 0，billed_ops = []）
（5）2014-01 -15 12：13：31.516GET ... / werkzeuge /200 real = 5176ms api = 0ms overhead = 9ms（96 RPC，cost = 0，billed_ops = []）
（6）2014-01- 15 12：13：00.507GET ... / einstieg /200 real = 5460ms api = 0ms overhead = 9ms（94 RPC，cost = 0，billed_ops = []）
（7）2014-01-15 12：12：59.891GET ... /302 real = 369ms api = 0ms overhead = 0ms（7 RPCs，cost = 0，billed_ops = []）
  

解决方案

在带有filer和简易缩略图的推荐设置中分析django-CMS与appstats之后，排除cloudstorage后，呈现新的未缓存空页使用远程数据库可以在不到500毫秒的时间内完成。

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

我们运行了一个远程数据库连接到本地机器Europe-USA上的SDK实例，从而将页面渲染时间增加到32秒。访问时间似乎与网络延迟和查询次数成线性关系。

该系统仍然可以与django的数据库缓存一起使用，但管理后端缓慢而无法使用方便。结论：django-CMS与任何云中的远程数据库设置都不兼容。

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

I have tried to run a django-CMS (+filer +easy_thumbnails) with a remote mysql DB on GoogleAppengine, with cloudstorage. After fixing file-system related performance problems and fork-fixing a django-google-cloud-storage module (http://github.com/locandy/django-google-cloud-storage), the performance is still beyond terrible (4s per request pre cache). Most things are configured as default from the tutorial.

Timing is for generic page rendering requests (no cache, not logged in, excluding instance start up time). The fastest is an empty page (no images, no text) with 1.7 seconds and 40 database RPCs. The slowest a full page with many images and some text at 4 seconds and 100 rdbms.Exec calls. I used the appengine python profiling module.

On average that would be 45ms per query.

Is there any configuration we have missed?

Did anyone succeed in deploying a CMS in the cloud with remote DB that is usable?

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',

Profiling:

  (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=[])

解决方案

After profiling django-CMS with appstats in the recommended setup with filer and easy-thumbnails and after excluding cloudstorage, it is not possible to render new uncached empty pages in less than 500ms with a remote DB.

Every placeholder or feature added to a page adds several sequentially executed queries. A complex page has up to 100 queries and a moderate page about 50. This adds up to 4-5 seconds rendering time for a page.

We have run a remote DB connection to a SDK instance on a local machine Europe-USA, which increased the page rendering time to 32 seconds. Access times seems to scale linear with network delay and number of queries.

The system can still be used with django's database cache, but the administrative backend is too slow to be used conveniently. Conclusion: django-CMS is not compatible with a remote DB setting in any cloud.

As a result of our tests we have fixed a uncached django storage module compatible with cloudstorage http://github.com/locandy/django-google-cloud-storage

这篇关于django-CMS与远程mysql数据库的性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！