優化 Nuwa_DjangoCMS

優化文件 (以 DjangoCMS 專案為例)

• 優化目的與基本概念
• 過程架構:
  • 瀏覽器畫面 render: pagespeed
  • 伺服器回應速度: silk
  • 資料庫 query 速度

優化目的與基本概念

優化目的

公司業務多是提供網站服務，除了專案的需求功能，也注重網站的使用者體驗，縮短網站載入內容的延遲時間是此次優化的目標，並以　Nuwa_DjangoCMS　的專案作為範例目標，測試如何原則性的優化所有部落格專案。

由於目標是優化部落格專案，以部落格文章列表為目標頁面，部落格資料的擷取、CMS 的　query 等都是由使用的套件完成，不涵蓋在本次優化的範圍。

基本概念

進行優化時，為了保證優化的效果可以數據化，需要記錄專案執行時的硬體設備等狀況，可以參考附檔中 優化文件.xlsx ，可以看到需要紀錄的項目。

優化不建議盲目的測試，建議先針對專案本身骎ˋ部分耗費時間佔比有所了解，再從嚴重的部分著手，基本 Django 優化可以參考 Django 官方優化文件。

上圖為 Django 的 flowchart，將正確內容的 response 傳給 browser 後， browser 會再將內容 render 出來顯示在使用者眼前，使用者的載入延遲時間受到這些步驟影響，因此我們可以大致將優化的架構分為三部分: 瀏覽器畫面 render、伺服器回應速度、資料庫 query 速度，以下針對這三個部分優化的過程說明。

瀏覽器畫面 render: pagespeed

這方面可以透過 google 的 pagespeed 作為初步診斷，並且評估優化的效果。

操作

至 Chrome 打開測試的專案目標頁面 (在 Nuwa_DjangoCMS 本機的測試中目標頁面是 http://127.0.0.1:8000/zh-hant/blog/)，按下 F12 (Fn + F12) 快捷鍵，可以選擇 Performance 的項目，觀察 render 的耗費時間比例 (如下圖) 也可以使用 Lighthouse，進行網頁的評分，以及提出優化的建議方向 (如下圖)。 參考: https://www.youtube.com/watch?v=5fLW5Q5ODiE

DjangoCMS 診斷建議有幾個方向:

• Cache
• unused css
• enormous payload

Cache

Django 對於 cache 有很多相關的設定可以使用，這些都可以在 Setting.py 快速設定，範例如下:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': [
            '127.0.0.1:8000',
        ]
    },
    'db': {
        'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}

unused css

因為使用 w3layout 的風格專案，要特別進行刪去沒有被使用的 css 檔難以統一對許多專案進行優化 (也考慮 css 可能有許多 RWD 的設定無法抽出)，因此可以考慮進行快取，在 template 的片段進行 cache。

enormouse payload

考慮專案為部落格網站，有很多圖片展示的需求，為了畫面的清晰度，部分圖片的檔案大小過大，上部分 css javascript 也成為 payload 的負擔，可以考慮使用 compress，範例如下:

{% compress css %}
<link rel="stylesheet" href="/static/css/one.css" type="text/css" charset="utf-8">
<style type="text/css">p { border:5px solid green;}</style>
<link rel="stylesheet" href="/static/css/two.css" type="text/css" charset="utf-8">
{% endcompress %}

輸出結果如下:

<link rel="stylesheet" href="/static/CACHE/css/output.f7c661b7a124.css" type="text/css" charset="utf-8">

將檔案內容的不必要空格刪去，降低可讀性，但是可以減輕檔案大小，不影響畫面效果。

也可以試試看 Gzip 的 Middleware ，將 request 進行壓縮，Settings.py 設定範例如下:

MIDDLEWARE = (
    'django.middleware.gzip.GZipMiddleware',
    ...
)

參考: https://django-compressor.readthedocs.io/en/stable/usage/

伺服器回應速度: silk

這方面就依照 django-silk 或是 debug 即可做出初步評估，不過 debugtool 會使載入速度降低很多，要注意在優化的時候不會交叉在前後端測試，但可能在優化進行到一個段落後，將 silk, debugtool 這種追蹤效能用實際專案運行時不需要的套件停用，測試優化結果。 silk 的設定按照 django-silk 官方文件 即可設定完成，使用頁面大概如下: 可以使用右方的篩選器，只選擇部分的 view 或是 request url ，選擇目標 request 可以觀看 detail: 也可以觀察 SQL 的細節: 或是針對特定 view (在此用 ArticleList 為範例) 掛上 decorator，即可觀察細部 profiling: debug tool 會在畫面中增加一個 toolbar，可以針對 flowchart 中的部分檢測:

也有專門可以視覺化 profiling 的套件可 視覺 profile: http://www.vrplumber.com/programming/runsnakerun/ https://github.com/jiffyclub/snakeviz https://jiffyclub.github.io/snakeviz/

範例結果如下:

資料庫 query 速度

資料庫的優化要考慮真實專案運行時使用 mariaDB 的狀況，所以需要使用 VM 的資料庫測試，可以針對 server 的資料庫進行設定，這部分的設定值可能受到 server 的效能影響，需要再多參考

可以參考 wrk, ab 或是 silk 這類的後端測試工具，檢查效果。 ab 的使用範例:

ab -c 10 -n 1000 http://127.0.0.1:8000/zh-hant/blog/

不過 ab 沒有列出 DB 單一部分的耗費時間，這部分用 silk 可能會更直接。