nginx + PHP-FPM + MariaDB + Varnishを使用した非常に気の利いたWordPressブログ

この記事では、適切なキャッシュ、圧縮、その他のサーバーおよびクライアント側の最適化により、WordPressブログがどのように機能するかについて説明します。 執筆時点で、VDSの機能は次のとおりです。

CPU：1 x 2GHz
HDD：10Gb
RAM：512Mb
OS：Debian 8 x64

システムのスキームは次のとおりです。

回路の説明

サイト訪問者の場合、それらはHTTPSにリダイレクトされ、nginxはVarnishのプロキシとして機能します。一方、nginxはHTTPS接続の実装に加えて、ユーザーに送信されるデータのgzip圧縮も実行します。 このシステムの次の要素は、ポート6081での接続を待機しているVarnish HTTP Acceleratorです。 クライアントからリクエストを受け取ると、キャッシュ内でリクエストされたURLを検索し、見つかった場合はすぐにフロントエンドを返します。 したがって、要求されたファイルがキャッシュ内にある場合、ページ要求の速度は静的データの要求の速度に低下します。 要求されたファイルがキャッシュに見つからない場合、Varnishは要求をバックエンドに渡します。 Varnishはクライアント側の最適化も実装します。ここでは、Cache-ControlヘッダーとExpiresヘッダーが静的データに設定され、クライアント側でこのデータをキャッシュする必要があることをブラウザーに示します。 したがって、サイトのロード時間が短縮され、サーバーの負荷が軽減されます。

繰り返しますが、nginxはバックエンドとして機能し、127.0.0.1：81で接続を待機します。 PHPの解釈は、FPMを使用して実装されます。 PHPバージョンは5.6で、OPcacheアクセラレーターはデフォルトで有効になっています。 DBMSとして-MariaDB10。これはパフォーマンスが最高の1つであり、MySQLのフォークの中で適度にRAMデータベースを消費します。 MyISAMはテーブルエンジンです。書き込みはめったに行われないため、主にこのエンジンが最適化される読み取りです。 InnoDBエンジンを無効にすることにより、RAMが保存されます。 最後に、WordPressはVarnish HTTP PurgeプラグインがインストールされたCMSとして機能し、変更が行われたページのアドレスにPURGEリクエストを送信します。これにより、これらのページのVarnishキャッシュがクリアされます。 したがって、ユーザーは常に最新バージョンのサイトを取得します。 次に、これらのコンポーネントのインストールと構成、および発生した問題について詳しく説明します。

nginxをインストールして構成する

インストール：

apt-get install nginx 

メイン設定/etc/nginx/nginx.confの内容：

 #   ,       user www-data www-data; #         auto worker_processes auto; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { #      worker_connections 1024; #    ( FreeBSD  kqueue) use epoll; #      multi_accept on; } http { #    mime-     - include /etc/nginx/mime.types; default_type application/octet-stream; #    nginx   server_tokens off; #    sendfile   read+write sendfile on; #   ,       sendfile().            sendfile_max_chunk 128k; #          tcp_nopush on; tcp_nodelay on; #        reset_timedout_connection on; #            client_header_timeout 3; client_body_timeout 5; #  ,       3  send_timeout 3; #        client_header_buffer_size 2k; client_body_buffer_size 256k; #      client_max_body_size 12m; #    access_log off; #    include /etc/nginx/conf.d/*.conf; } 

バックエンド構成ファイル/etc/nginx/conf.d/backend.confを作成します。

 server { #     81  listen 127.0.0.1:81; #      root /var/www/site.ru/public_html; index index.php; #  gzip-   .       .     9  .  ,    text/plain,       1  ,      CPU     gzip on; gzip_comp_level 9; gzip_min_length 512; gzip_buffers 8 64k; gzip_types text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml; gzip_proxied any; #   server_name site.ru www.site.ru; #       location ~ /\. { deny all; } #       location ~* /(?:uploads|files)/.*\.php$ { deny all; } #   URI    location / { try_files $uri $uri/ /index.php?$args; } #       */wp-admin rewrite /wp-admin$ $scheme://$host$uri/ permanent; location ~ \.php$ { #   404  ,  WordPress try_files $uri =404; #    php     FPM include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/var/run/php5-fpm.sock; } } 

nginxのHTTPS設定の詳細な説明のトピックについては、この記事を読むことをお勧めします： habrahabr.ru/post/252821
フロントエンド構成ファイル/etc/nginx/conf.d/frontend.confを作成します。

 server { #   HTTPS listen REAL_IP:80; server_name site.ru www.site.ru; return 301 https://$server_name$request_uri; } server { listen 93.170.105.102:443 ssl; server_name site.ru www.site.ru; #  Keep-Alive    keepalive_timeout 60 60; #     .  ,      text/plain,            ,       .   ,     CPU    . gzip on; gzip_comp_level 1; gzip_min_length 512; gzip_buffers 8 64k; gzip_types text/plain; gzip_proxied any; #   ,    ssl_prefer_server_ciphers on; #   TLS   2  ssl_session_cache shared:TLS:2m; ssl_session_timeout 2m; #  ,       ssl_certificate /etc/ssl/combined.crt; #    ssl_certificate_key /etc/ssl/3_site.ru.key; #    - ssl_dhparam /etc/ssl/dh2048.pem; #   ssl_protocols TLSv1.2 TLSv1.1 TLSv1; #  ,    forward secrecy ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA512:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:ECDH+AESGCM:ECDH+AES256:DH+AESGCM:DH+AES256:RSA+AESGCM:!aNULL:!eNULL:!LOW:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS; #  Strict-Transport-Secutiry  add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains'; location / { #   Varnish proxy_pass http://127.0.0.1:6081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-Port 443; } } 

nginxの設定を読み直します：

 service nginx reload 

ここで、サイトにアクセスしようとすると、エラー502が表示されます。ワニスはまだ実行されていないため、これは正常です。

Varnishをインストールして構成する

ニスをインストールします。

 apt-get install varnish 

起動パラメータファイルはここにあります-/ etc / default / varnish。 DAEMON_OPTSで、次のパラメーターを設定します。

 DAEMON_OPTS="-a :6081 \ -T 127.0.0.1:6082 \ -f /etc/varnish/default.vcl \ -S /etc/varnish/secret \ -s malloc,128m" 

-a-Varnishが接続を受け入れるポートを設定します。この場合、フロントエンドから-nginx。
-T-管理者がここで回転しています。詳細は-Sフラグの説明です。
-f-VCL構成ファイル、要求の処理とVarnishでのキャッシュのルールを定義するための特別な言語。
-S-Varnishには管理パネルがあります。 入力するには、varnishadmコマンドを実行する必要があり、ユーザーは認証のために/ etc / varnish / secretファイルへの読み取り権限を持っている必要があります。
-sは、キャッシュの場所とそのサイズ（この場合はRAMの128MB）を示します。

おそらく既に理解しているように、最も興味深いのは、リクエストを処理するためのルールを含むファイルで私たちを待っていることです。 Varnishプロセスの開始時に、このファイルがコンパイルされます。 VCLは、これらのルールを説明するいくつかの機能サブセクションを使用します。 それらについて簡単に説明し、公式ウェブサイトで読むために完全な説明をお勧めします。

sub vcl_recv-この関数は、クライアントから要求が来たときに使用されます。
sub vcl_pass-クライアント要求をバックエンドに直接渡す必要がある場合に実行され、キャッシュせず、キャッシュ内で一致するものを探しません。
sub vcl_hash-キャッシュルールを定義します。たとえば、クライアントによる圧縮のサポート、またはクライアントの他の機能など、異なる条件に応じて、同じドキュメントに対して複数のリポジトリを使用できます。 私たちの場合、Varnishのクライアントはフロントエンドにnginxしかないため、使用されません。
sub vcl_backend_response-この関数は、リクエストがバックエンド（nginx）から来たときに使用されます。
sub vcl_deliver-クライアントにデータを送信する直前に使用します。たとえば、ヘッダーを追加/変更します。

VCLコンポーネントの操作図は、次のように表すことができます。



vcl_miss関数からバックエンドにアクセスすると、バックエンドの応答もキャッシュに送信されます。 言語自体はCに非常によく似ています。始めましょう。 ファイル/etc/varnish/default.vclを開き、コーディングを開始します。

 #    ,     VCL 4 vcl 4.0; #   backend default { .host = "127.0.0.1"; .port = "81"; } #  IP/,    PURGE-    acl purge { "localhost"; "127.0.0.1"; } #     sub vcl_recv { #      if (req.method == "PURGE") { #     ,   if (!client.ip ~ purge) { return(synth(405, "This IP is not allowed to send PURGE requests.")); } return (purge); } # POST-     Basic-  if (req.http.Authorization || req.method == "POST") { return (pass); } #      if (req.url ~ "wp-(login|admin)" || req.url ~ "preview=true") { return (pass); } #  sitemap   robots,   sitemap   Google XML Sitemaps if (req.url ~ "sitemap" || req.url ~ "robots") { return (pass); } #  cookies,  "has_js"  "__*",  CloudFlare  Google Analytics,   Varnish    ,    cookies. set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", ""); #   ";"  cookies,     set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); #  Quant Capital cookies (  ) set req.http.Cookie = regsuball(req.http.Cookie, "__qc.=[^;]+(; )?", ""); #  wp-settings-1 cookie set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", ""); #  wp-settings-time-1 cookie set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?", ""); #  wp test cookie set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(; )?", ""); #  cookie,     (  ) if (req.http.cookie ~ "^ *$") { unset req.http.cookie; } #      cookies,    if (req.url ~ "\.(css|js|png|gif|jp(e)?g|swf|ico|woff|svg|htm|html)") { unset req.http.cookie; } #   cookies "wordpress_"  "comment_"     if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~ "comment_") { return (pass); } #  cookie  ,         if (!req.http.cookie) { unset req.http.cookie; } #      cookies,     WordPress if (req.http.Authorization || req.http.Cookie) { # Not cacheable by default return (pass); } #    return (hash); } sub vcl_pass { return (fetch); } sub vcl_hash { hash_data(req.url); return (lookup); } #     sub vcl_backend_response { #    unset beresp.http.Server; unset beresp.http.X-Powered-By; #     robots  sitemap if (bereq.url ~ "sitemap" || bereq.url ~ "robots") { set beresp.uncacheable = true; set beresp.ttl = 30s; return (deliver); } #   ,   ... if (bereq.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico|woff|svg|htm|html") { #    unset beresp.http.cookie; #      -  set beresp.ttl = 7d; #   Cache-Control  Expires,    ,                unset beresp.http.Cache-Control; set beresp.http.Cache-Control = "public, max-age=604800"; set beresp.http.Expires = now + beresp.ttl; } #       if (bereq.url ~ "wp-(login|admin)" || bereq.url ~ "preview=true") { set beresp.uncacheable = true; set beresp.ttl = 30s; return (deliver); } #         ,     if (!(bereq.url ~ "(wp-login|wp-admin|preview=true)")) { unset beresp.http.set-cookie; } #      POST-  Basic  if ( bereq.method == "POST" || bereq.http.Authorization ) { set beresp.uncacheable = true; set beresp.ttl = 120s; return (deliver); } #     if ( bereq.url ~ "\?s=" ){ set beresp.uncacheable = true; set beresp.ttl = 120s; return (deliver); } #    ,     ! if ( beresp.status != 200 ) { set beresp.uncacheable = true; set beresp.ttl = 120s; return (deliver); } #          set beresp.ttl = 1d; #       TTL set beresp.grace = 30s; return (deliver); } #      sub vcl_deliver { #    unset resp.http.X-Powered-By; unset resp.http.Server; unset resp.http.Via; unset resp.http.X-Varnish; return (deliver); } 

次に、コマンドを実行します。

 service varnish restart 

ブラウザでサイトに渡ると、index.phpが表示されます。これは事前に作成する必要があります。

ニスとDebian 8の問題

しかし、Varnishが着信接続を受け入れるポートを変更する場合、またはキャッシュサイズを変更する場合はどうでしょう。 公式ドキュメントから判断すると、パスに沿って配置されたVarnish起動パラメーターを使用してファイルを変更する必要があります：/ etc / default / varnishそしてサービスを再起動します。 しかし、違います！ 何も変更されません。先頭に移動して「c」キーを押すと、以前の設定でサービスが開始されていることがわかります。 問題は、Debianの新しいバージョンでは、init.dの代わりにsystemdが初期化システムとして使用されるため、/ lib / systemd / system / varnish.serviceファイルに移動して、ExecStartディレクティブに同じ起動パラメーターを書き込む必要があるということです。

 [Unit] Description=Varnish HTTP accelerator [Service] Type=forking LimitNOFILE=131072 LimitMEMLOCK=82000 ExecStartPre=/usr/sbin/varnishd -C -f /etc/varnish/default.vcl ExecStart=/usr/sbin/varnishd -a :6081 -T 127.0.0.1:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,128m ExecReload=/usr/share/varnish/reload-vcl [Install] WantedBy=multi-user.target 

保存後、次のコマンドを実行して変更を有効にします。

 systemctl daemon-reload service varnish restart 

現時点では、この問題はいつ、どのように解決するかは不明であるため、開発者に書き込まれます。そのため、更新後に一度すべてが落ちないように、両方のファイルに同じ変更を加えてください。

PHP-FPMのインストールと構成

DBMSを使用するためにFPMとPHPライブラリをインストールします。

 apt-get install php5-fpm php5-mysqlnd 

構成ファイル/etc/php5/fpm/pool.d/www.confに移動して、ディレクティブを変更します。

 listen = 127.0.0.1:9000 

以下へ：

 listen = /var/run/php5-fpm.sock 

同じファイルで、ワーカーの設定を設定します。

 ;     pm = dynamic ;   ,   ,     pm.max_spare_servers. pm.max_children = 10 ;      FPM pm.start_servers = 1 ;     (     ) pm.min_spare_servers = 1 ;     ( ,    ) pm.max_spare_servers = 3 ;   ,    ,    pm.max_requests = 500 

/etc/php5/fpm/php.iniのいくつかのディレクティブを変更します

 upload_max_filesize = 10M post_max_size = 12M allow_url_fopen = Off 

post_max_sizeは、upload_max_filesizeよりも少し大きく設定されます。これは、ファイルに加えて、リクエストに他のデータが含まれるためです。
ここでは、allow_url_fopenディレクティブを使用して、リモートにあるスクリプトの実行を禁止しています（リモートインクルードの脆弱性を悪用する可能性を排除しています）。

そして、設定を再読み込みするようFPMに指示します。

 service php5-fpm reload 

phpinfo（）を出力するファイルを作成し、ブラウザでアクセスすると、すべてが機能するはずです。 既にニスにキャッシュされていることを忘れないでください。PHPの構成を変更しても、ブラウザーで更新されません。 このファイルをVarnishでスキップするルールを作成するか、Varnishではなくプロキシをテスト中にポート81のバックエンドに直接プロキシすることができます。

MariaDBをインストールして構成する

このDBMSを選択した理由は、パフォーマンスが高く、重い負荷に耐える能力があり、MySQLと比較してRAMの消費量が少ないことと、WordPressとの完全な互換性があるためです。 インストールは非常に簡単で、rootユーザーのパスワードが要求されます。

 apt-get install mariadb-server 

MyISAMはテーブルエンジンとして使用します。これは、テーブルへの書き込みがまれであり、読み取り時にMyISAMが最高のパフォーマンスを発揮するためです。 InnoDBサポートを完全に無効にして、RAMを解放しました。 設定は/etc/mysql/my.cnfファイルに保存されます。 変更したディレクティブのみを説明します。

 #        key_buffer = 64M #   query_cache_size = 32M #  MyISAM     default-storage-engine=MyISAM #   InnoDB skip-innodb 

変更を保存した後、サービスを再起動します。

 service mysql restart 

WordPressのカスタマイズ-ニスHTTPパージプラグイン

WP管理パネルで「Varnish HTTP Purge」プラグインをインストールします。 現在、データを更新すると、変更されたページにPURGEリクエストが送信され、Varnishのキャッシュがクリアされ、訪問者のデータは常に更新されます。

追加の最適化

Varnishでクライアント側を最適化するために、ローカルクライアントキャッシュに静的データを保存するようブラウザーに指示します。 ただし、さらに最適化する場合は、 developers.google.com / speed / pagespeed / insightsにアクセスして、サイトのURLまたは特定のページを入力してください。 推奨事項のリストと、cssおよびjsスタイルの圧縮バージョンを含むアーカイブが提供されます。 あなたのウェブサイトでそれらを置き換え、転送されるデータの量が減少するため、ダウンロード速度がさらに速くなります。サーバーの負荷とキャッシュ内のこれらのファイルが占有するスペースも減少します。

フォントやjqueryライブラリなど、サードパーティのサーバーから要求されたドキュメントをどうしますか？ それらを自分自身に転送できます。ここでは、1つのサーバーにのみ接続することで、ページの読み込み速度が向上しますが、同時にヒットのリストと全体的な読み込みが増加します。 どのオプションを選択するか-サーバーの負荷と遅延に応じて、自分で決定してください。

まとめ

ほとんどの場合、ワニスのgzip圧縮とキャッシュが最大の効果をもたらします。 多くの追加の最適化手法がすでにコメントに記述されていますが、必要に応じて確実に調査して実装します。 それまでの間、最適化の結果は次のとおりです。
に

後

少し後で本格的なストレステストを実施します。

ソース： webshake.ru/post/206