最小システム要件のためのdjango上のプロジェクトのフラットページの最適化。 冗談の記事

カットの下にたくさんの文字がありますが、心配しないでください-あなたはすべてそれらを知っています。

背景

とても面白い



むかしむかし、最愛の人と一緒に、最初の小さなプロジェクトを作ろうとしました。 それから私はデザインだけに従事していたので、プログラマーを雇わなければなりませんでした。私は彼にレイアウトを渡し、彼はレイアウトとアプリケーションそのものを教えてくれました。 ホスティングには約130から150ルーブルの費用がかかりました-もちろん、それはLAMPでした。



通常、最初のパンケーキはうまくいきませんでした。 時間が経ち、私たちは2番目のプロジェクトに熟しました。 今、私は自分ですべてを行うことができました。 設計を破棄した後、レイアウトを設定し、次にアプリケーション自体を設定しました。 今回は重要なことではありません：静的な要素がたくさんある単純なサイトは面白くないです。



習慣から、私はこのようにそれを考え出した：VPSの関税ページを開き、下から最初の行を選択する-まあ、約800から1000ルーブルのどこか。 「そんなに？」 私たちはかつて200ルーブルを支払いました...」-配偶者は困惑しました。 確かに、なぜもっとですか？ もちろん、答えは明らかです。空軍、あなたが私に言わなければ、ジャンガはあちこちにあります、「これはあなたのためのジュムラではありません！」-しかしジュムラはどうですか？ ジュムラ、優勝：100ルーブル。 1か月間幸せに暮らします。 しかし、これはあまりにも単純な答えなので、面白くありません。

挑戦する

そして、私たちにはタスクがあります：最小CPとdjangoの完成プロジェクト-静的、いくつかのフォーム、管理パネルなど。 合成最小：ネジに200 MB RAM、500 MHzパーセント-システムと一緒にすべての2つのギグがあるようにします。

DB

タスクのボトルネック：RAM。 sqliteを使用します。 待って なに？！ 真剣に、彼はそんなに悪くない 。 キャッシュの欠点を補います。

キャッシュ

最も強力なものすべて：nginx + memcachedを使用して、jungaとの連携方法を教えます。

Webサーバー

それはuwsgiになります-高速でファッショナブルです。 球形真空のファンについては、 テストをご覧ください 。

セッション

セッションはどこかに保存する必要があります。 私は通常redisを使用しますが、ここでは使用しません。 Memkeshdも適切ではありません。キャッシュアーキテクチャを考えると、多くの場合、キャッシュ全体をフラッシュし、それらを使用してセッションが削除されます。 Jung 1.4の新機能が役立ちます。 これはCookieベースのセッションです。 原則は単純です。すべてのセッションデータはユーザーのCookieに保存されます。 データ自体は暗号化されませんが、完全性は暗号署名によって保証されます。 ドックで詳細をご覧ください。

内容

ここでは、MarkDownを使用します。 「なぜマークダウン？」 彼はかっこいい。 彼はすごい。 この記事でも私はそれについて書いています。 データベースのサイズを緩和するのに役立ちます。タグは含まれていません。 MDのテキストは、fckeditorのエディターと同じくらい簡単な場合があり、100回に1回は目を楽しませてくれます。 さらに、テキストはエディターではなくサイトのスタイルでフォーマットする必要があります。一部のスタイルは、サウロンのようにすべてを支配します。

ソフトウェア

Ubuntuサーバーを最小限にして、最新かつ最速のソフトウェア、nginx、memcached、python 2.7を入手します。 一般的に、slitaz、puppy linux、slaxのような簡単なものを使用する方が良いです-ubuntの最小値が128 MBのRAMであり、構成された「ベースシステム」+いくつかのソフトウェアがネジに1ギガバイト以上あるからです。 サーバー配布、 サー 。 しかし、私たちはこの記事を楽しむことにしました。一般的に、私たちはその対策を知っています。

開発

ジャンゴ

まず、dzhangi configをセットアップする必要があります。

#     . #   ,       js. SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies' SESSION_COOKIE_HTTPONLY = True # https://docs.djangoproject.com/en/1.4/ref/settings/#std:setting-USE_I18N #    .    : This provides an easy way to turn it off, for performance.       ,     ,      USE_I18N = False # https://docs.djangoproject.com/en/1.4/ref/settings/#use-l10n #       .    pytils    . USE_L10N = False # https://docs.djangoproject.com/en/1.4/ref/settings/#use-tz #      USE_TZ = False #  ,     .      . TEMPLATE_CONTEXT_PROCESSORS = ( # default template context processors "django.contrib.auth.context_processors.auth", # "django.core.context_processors.debug", # "django.core.context_processors.i18n", # "django.core.context_processors.media", "django.core.context_processors.static", #"django.core.context_processors.tz", "django.contrib.messages.context_processors.messages", # required by django-admin-tools 'django.core.context_processors.request', 'orangetrans.utils.context_processors.common', ) # Sentry     ,     . # include_html     ,       . #        . # https://docs.djangoproject.com/en/1.4/topics/logging/#django.utils.log.AdminEmailHandler LOGGING = { … 'handlers': { 'mail_admins': { 'level': 'ERROR', 'filters': ['require_debug_false'], 'class': 'django.utils.log.AdminEmailHandler', 'include_html': True, } }, … } #       ""  SEND_BROKEN_LINK_EMAILS = True
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュ

これはプロジェクトの最も強力な部分です。 キャッシュは、遅いバックエンドの前のシールドになります。 もちろん、多くはすでにそれが何であるかを推測しています。



どのように機能しますか？ それは簡単です：ユーザーがページをリクエストし、nzhinksはこのページがキャッシュにあるかどうかを確認します。そうでない場合、dzhangはそれを生成し、キャッシュに入れてnzhinksに渡します。 つまり 実際、一度サイトを通過するだけで十分であり、その後のすべての時間、サイトはmemcashd + nzhinksの速度で動作します。



本当に素晴らしい？ まあ、ほとんどの場合、このタイプのキャッシュは私たちのケースに適しています。複雑なプロジェクトには、多くの欠点があります。 たとえば、ユーザーが入力したフォームを更新することはできません。なぜなら、このURLを通過するたびに、ユーザーはキャッシュから同じフォームを取得するからです。 ファッションを称賛する必要はありません:)

ジャンゴ

フォームはAjaxで送信され、一度表示すれば十分です。データとエラーは既にjsに送られます。 Ajaxなしのフォールバックオプション（常に実行しますか？:)キャッシュしません。 私たちが投稿を通して取り組んでいるフォームはまだあります。 一部のバージョンのジャングル（1.2？）から、POST要求の場合、 csrf攻撃に対する保護が必須になりました。 私たちの場合、これはコールバックリクエストです。番号の1つのフィールドであり、個人データはありません。 特定のビューの保護をオフにするには、 csrf_exemptデコレータでラップするだけです。



計画を実行するために、ミドルウェアを作成します。 インターネットには、そのようなバンドルの作業を実装する方法に関する記事があります。 それは以前のバージョンのdzhanga向けに書かれたものであり、rawを見ることなく、それを理解することができませんでした。 私はそれを修正し、バカに更新します。 ミドルウェアでは：

 import re from django.core.cache import cache from django.conf import settings class NginxMemCacheMiddleWare: def process_response(self, request, response): url = request.get_full_path() cache_it = not settings.DEBUG \ and request.method == 'GET' \ and response.status_code == 200 if cache_it: stoplist = [ x for x in settings.CACHE_IGNORE_REGEXPS if re.match(x, url) ] if not stoplist: cache.set(url, response.content) return response
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GETのみをキャッシュし、開発時と404にはキャッシュしません。そしてなぜですか？ しかし、管理パネルまたは攻撃者自身を探しているボットは、あらゆる種類のジャンクでメモリを埋めることができるためです。



構成に戻りましょう：

 CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': 'unix:/tmp/memcached.sock', 'KEY_PREFIX': 'YOURSITE', } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここではすべてが簡単です。バックエンドmemkeshd、ソケット、プレフィックス。 ところで、私はpylibmcをソケットから取得できませんでした。彼はそこに何かが好きではありません。 python-memcachedを使いました。

 CACHE_IGNORE_REGEXPS = ( re.compile(r'/admin.*'), re.compile(r'/some_url.*'), )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、キャッシングが禁止されているURLのリストです。 設定でMIDDLEWARE_CLASSESに新しいミドルウェアを追加することを忘れないでください。



ところで、memcashdのステータスを監視するには、 django-memcache-statusプログラムを使用できます。 彼女は、管理パネルでmemcashdの使用済みメモリのスケールを描画し、あらゆる種類の情報を表示します。 正直なところ、私はそれをあまり使用していませんでした:)フラットページ管理者のためにすでに退屈な管理者を希釈するだけです。 残念ながら、彼女はdjango-admin-toolsと友達ではありません。

Nginx

サーバーdevの設定、後で更新します：

 upstream dev { server 127.0.0.1:8000; } server { listen 80; server_name dev.local; charset utf-8; location ~^/(media|static) { root /home/user/project; access_log off; break; } location / { if ($request_method = POST) { proxy_pass http://dev; break; } default_type "text/html; charset=utf-8"; set $memcached_key "YOURSITE:1:$request_uri"; memcached_pass unix:/tmp/memcached.sock; error_page 404 502 = @fallback; } location @fallback { proxy_pass http://dev; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の行を参照してください： 'set $ memcached_key "YOURSITE：1：$ request_uri";'？ ここですべての魔法が発生します。 各ページは、キープレフィックス+キャッシュのバージョン+完全なURLによってキャッシュに保存されます。 一度ページを開くだけで十分です。dzhangaはそれをキーのキャッシュに入れ、次にnzhinksがこのキーでそれを取得します。 dzhangaサイトをオフにしても動作します。 memcashdをプルすることなく、すぐにリクエストをバックエンドに送り返します。 別のポイント：ユーザーがjsを無効にしている場合、フルバックモードにget-keysを使用します（noscript：Pがあります）：すべての種類のタブがあるため、uriの代わりにrequest_uriがget-keysのない最後のURLです。



janga 1.3以降、キー全体を自分で生成する必要はありません。 set（）、get（）、delete（）メソッドに一意の部分を渡すだけで十分で、残りはjungが個別に実行します。 この場合のユニークな部分は、絶対ページURLです。



通常のgzipには小さな問題があります：nzhinksはmemkeshdから取得したものを圧縮しません。 私はネットワーク上で4年前にNinxのバージョン0.6のパッチを見つけました。すでに1 *です。 IE6を提供しない場合は、jung自体で圧縮を有効にし、すでに圧縮されたコンテンツを提供できます。 私たちの場合、スターターブラウザーは重要です。 それ以外の場合は、gzipが機能します。

Memecached

ソケット/etc/memcached.confを介して動作するようにmemcachedに伝えましょう：

 #-s unix socket path to listen on (disables network support) -s /tmp/memcached.sock #-a access mask for unix socket, in octal (default 0700) -a 0777
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

静力学

IEにはjqueryとhtml5shimを使用しています。 Googleを称賛してください、それは私たちの運命を促進します：

 <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

django-compressorを使用して、残りの統計を圧縮します。 django-compressorはcssでコンパイルすることもできます。 あまり使用しない場合は、サーバーとコンパイラ自体にnode.jsを配置することを忘れないでください。 すべての静的に対して、圧縮を有効にし、jsとjs、css c cssを結合します。 美人



また、アプリケーションはファイルに一意の名前を付けるため、ソースを変更すると、新しい名前の新しい名前がコンパイルされるため、ユーザーはそれらを新しい名前でダウンロードし、「なぜすべてがそんなに奇妙に見えるのか？」という質問をしません。 ちなみに、Dzhanga 1.4はそれもできます。

ローカルテスト

さて、ほぼ完了です。

お気に入りの仮想マシンを使用して、システムをインストールし、プロジェクトを展開します。 同時に、本番用のすべてを準備します。pipの要件を更新します。これは、何らかの理由で常に最新ではなく、uwsgiサーバーを構成します。 プロセッサには1つのポイントがあります。仮想ボックスとプレーヤーは特定の数のヘルツを与える方法がわからないため、1つのコアに制限します。



uwsgiサーバーの構成については、 ドックとwelinuxに関する別の記事を読むことをお勧めします 。 ここで説明するのは無意味です。ドックから設定の例を取り上げて実行します。 推奨される唯一の推奨事項はvirtualenvです。 これは、ほとんどの問題がpythonpathと環境に関するものであるためです。ああ、ドックの見方を理解する前にどれだけの時間を殺したかです。 Googleによる判断：私は1人だけではありません。人々はできる限り倒錯しています：スクリプトなどから環境にパスを追加します。 そして、古き良きrtfm。



これで、すべての準備が整いました。 ブラウザでプライベートモードを開き、すべてが公平になるように、ページを取得する量を測定します。

 18 requests ❘ 284.93KB transferred ❘ 1.11s (onload: 1.12s, DOMContentLoaded: 979ms)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュをオンにしてキャッシュを生成し、新しいプライベートブラウザを開きます。

 18 requests ❘ 298.09KB transferred ❘ 291ms (onload: 293ms, DOMContentLoaded: 150ms)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

POSTリクエストを実行しましょう（その理由を説明します）。 get_or_createを数回実行します。

 21 ms.  .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、gzipを使用せずに重量が少し増えるだけでなく、増加しています。

かっこいい かっこいい。

より涼しくすることができます

ここに私たちがやることがあります：

• バージョン1.3以降、ジャングルはすべてのアプリケーションのすべての静的データを静的ファイル（manage.py collectstatic）を持つフォルダーに収集します。これ以上は想像できません。 すべてをメモリに入れます。
• このファイルがあり、アプリケーションはそれをファイルとしてアクセスし、メモリに入れます。
• ネジで1時間に1回コピーを設定して、静かに眠ります。

Staticsは2メガバイトであり、データベースは数メガバイトを超えることはありません-5 MBを使用します。 メモリ内にディレクトリを作成します。

 #    /etc/fstab: tmpfs /mnt/project/ tmpfs size=5M,mode=0777 0 0 #   $ sudo mkdir /mnt/project/ #     ,     : $ sudo mount /mnt/project/ # mode=0777    ,    $ mkdir /mnt/project/static $ mkdir /mnt/project/db
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトを正しくアセンブルした場合、所有しているすべての統計はアプリケーションディレクトリにあります。 これを行うには、各アプリケーションの静的に静的を追加する必要があります。詳細は、 ドックに追加してください。 そのため、dzhangaは適切な場所でそれらを見つけて収集することができます。 私たちはやる：

 #          . #    ,    : STATIC_ROOT = COMPRESS_ROOT = '/mnt/project/static/' #     (--noinput    ,  -      ): $ ./manage.py collectstatic --noinput -c #    .     : DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': '/mnt/project/db/db', } } #   $ cp -r project/db /mnt/project/db/db #   $ killall -HUP uwsgi
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このすべての自動化を最初に残し、バックアップを宿題としてクラウンに残します。



njinks設定を更新します。

 upstream project { server unix:/tmp/project.sock; } server { listen 80; server_name project.ru www.project.ru; if ($host = www.project.ru){ rewrite ^(.*)$ http://project.ru$1 permanent; } location /static { root /mnt/project/; access_log off; expires max; } location /media { root /project/; access_log off; expires 5d; } location / { include /etc/nginx/uwsgi_params; if ($request_method = POST) { uwsgi_pass project; } default_type "text/html; charset=utf-8"; set $memcached_key "project:1:$request_uri"; memcached_pass unix:/tmp/memcached.sock; error_page 404 502 = @fallback; } location @fallback { include /etc/nginx/uwsgi_params; uwsgi_pass project; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メディア、私たちは物理的にそこにとどまりました。 静力学は動きました、残りはすでに見ました。

静的変数の「expires max」という行に注目する価値があります。これはクールではありません。 しかし、明日写真を修正したらどうなりますか？ django-compressorを使用している場合、css：/static/i/button-small.png?e59177bafc62でこれを見て驚くでしょう。



キャッシュなし：

 14 requests ❘ 284.93KB transferred ❘ 743ms (onload: 775ms, DOMContentLoaded: 708ms)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシュあり：

 14 requests ❘ 298.09KB transferred ❘ 174ms (onload: 175ms, DOMContentLoaded: 140ms)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

POST：

 17ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

増加があります。 小さいけれど そして、出席者が増えると、これは顕著になります。

バックアップ

私は通常非常に無駄が多いのでDropboxを使用していますが、 ここではWebDavの方が適しています 。 MyDriveには、簡単でかなり詳細な手順が記載されています。 利点は現在、サービスでいっぱいです-選択してください。 これにより、ネジのスペースを節約し、同時にクラウドへのバックアップを取ることができます。

それで、私たちは何をしましたか？

• mysqlをsqliteで置き換えることでリソースを節約しました（dbをメモリに入れることで少し費やしました:)が、とりあえずは非常に高速になりました。
• Cookieベースのセッションを使用-ユーザーとのセッションであるため、ストレージ、クリーニング、その他のナンセンスについて心配する必要はありません。
• 翻訳を無効にすることで、主に管理パネルであるdzhangaの作業を最適化しましたが、これはキャッシュされない部分であり、重要です。
• Nzhinks、dzhanga、およびmemkeshdは、ソケットを介して通信します-追加する量はわかりませんが、ポートを介した場合よりも高速になります。
• おそらく、既存のキャッシュの中で最速のキャッシュを使用しました。正しく使用すれば、より良いサイトへの速度を向上させることができます。
• 静的の一部は外部に配置されます。つまり、サイトはさらに高速にロードされます。異なるソースから、またはローカルキャッシュ（一般的なもの）から。
• 静的データを圧縮してメモリに格納し、nzhinksを介して提供します。
• バックアップ？ チェック済み

冗談は何ですか？

好奇心と厳しい条件で働く習慣から、そのように問題を解決することは私にとって興味深いことでした。 基本的に、ソリューションは無害で有用ですらありますが、一部は本質的にスポーティです：選択されたキャッシュは非実用的であり、sqliteではプロジェクトを大幅に拡張することはできません（たとえば、コールを処理するためのバックオフィス）。 そして、私の心では、サーバーに保存しないので、これはすべてファンにすぎません。



すべてのようです。 ご清聴ありがとうございました。