非共有ホスティングに関するWordPressマルチサイトに最適なキャッシュオプションは何ですか?
-
16-10-2019 - |
質問
どのキャッシングプラグイン構成を推奨していますか、そして次の仮定の下でなぜ推奨していますか:
- サーバー構成の完全な制御
- マルチサイト/マルチドメインモードでWordPressを実行します
- ほとんどのドメインは使用していません
www.
プレフィックス(クッキー) - (欲求)特定のIPのキャッシュを無効にしたり、Cookieに基づいてキャッシュを変更したりすることができるようになります。キャッシュは必要ありません。
詳細:Firefox Google Page Speedプラグインを使用して、Webサイトの速度を最適化しようとしています。
また、小さな画像のように、一般的なガイドラインをガイドしないでください。
公平を期してください。複数のキャッシュプラグインを使用すると、解決するよりも多くの問題が発生するため、簡単なアプローチを提供してください。
解決
「プラグイン」に対する基本的な答えはおそらく W3合計キャッシュ. 。これは、最も機能的で積極的に開発されたプラグインの1つです。ただし、完全なパフォーマンスチェーンは、WordPressプラグインだけが処理できるほど長くなります。
- Webサーバー(Apacheまたは他の何か)構成(応答時間、最初のバイトまでの時間、ヘッダー)。
- データベース(クエリの処理に費やした時間)。
- PHP/WordPress(ページ生成時間、メモリ消費)。
- フロントエンドパフォーマンス(HTTP要求の量、帯域幅)。
良いスタートは、オペコードメモリベースのキャッシュを備えた静的キャッシュプラグイン(W3のような)です APC.
しかし、そこからは、コンテンツ配信ネットワーク、代替Webサーバーなど、できることができる(そしてはるかに複雑な)ことがあります。
他のヒント
私のWordPressパフォーマンスとキャッシュスタック
これは、低範囲からミッドレンジシングルサーバーまたはVPSに最適なWordPressパフォーマンススタックです。私は、約1gのメモリとかなり高速なドライブを備えた単一のコアとしてミッドレンジを分類しています。
サーバースタック
- Linux -Debian LennyまたはUbuntuのいずれか
- nginx-逆プロキシ静的ファイルキャッシュとして構成
- Apache -Apacheは、NginxによってオフロードされたPHPを代替ポートで処理します
- mysql- WPが必要とするには、最新の安定したバージョンを実行していることを確認してください
- PHP- 5.2または5.3ブランチの最新の安定バージョン
PHPキャッシュ
- APC -MMAPメモリと少なくとも128mのSHMサイズで構成
WordPressパフォーマンスプラグインスタック
- nginxプロキシキャッシュインテグレーター
- W3合計キャッシュ -diskにページキャッシュを設定し、ディスクに縮小し、オブジェクトとdbをAPCにマイニーします。
- セルフホストCDN-静的ファイルを提供するためだけにセットアップされたサーバー上のドメインを指す4つのCNAMEエイリアスを作成します
w3合計キャッシュを使用すると、nginxが静的ファイルを非常に高速に提供するため、ページキャッシュにディスクを使用してマイニル化します。
静的ファイルを提供し、PHPをApacheに渡すようにnginxを構成する方法
Apacheのみを使用することの問題は、静的ファイルでも接続を開き、すべてのリクエストでPHPにヒットすることです。 Apacheはそれらを開いたままにし、多くのトラフィックがある場合、接続が使用されていなくても接続が停止するため、これは接続を無駄にします。
デフォルトでは、Apacheは、デフォルトのWebポートであるポート80のリクエストを聴きます。まず、Apache Confと仮想ホストファイルに変更を加えて、ポート8080でリッスンします。
Apache Config
httpd.conf
KeepAliveをオフに設定します
ports.conf
NameVirtualHost *:8080
Listen 8080
サイトごとの仮想ホスト
<VirtualHost 127.0.0.1:8080>
ServerAdmin info@yoursite.com
ServerName yoursite.com
ServerAlias www.yoursite.com
DocumentRoot /srv/www/yoursite.com/public_html/
ErrorLog /srv/www/yoursite.com/logs/error.log
CustomLog /srv/www/yoursite.com/logs/access.log combined
</VirtualHost>
また、インストールする必要があります mod_rpaf したがって、ログには訪問者の実際のIPアドレスが含まれます。そうでない場合、ログは発信するIPアドレスとして127.0.0.1になります。
nginx config
Debianでは、リポジトリを使用してインストールできますが、バージョン0.6.33のみが含まれています。後のバージョンをインストールするには、Lenny Backportsパッケージを追加する必要があります
$ nano /etc/apt/sources.list
この行をファイルに追加します deb http://www.backports.org/debian lenny-backports main
$ nano /etc/apt/preferences
ファイルに以下を追加します。
Package: nginx
Pin: release a=lenny-backports
Pin-Priority: 999
backports.orgからキーをインポートするには、次のコマンドを発行して、パッケージを確認し、システムのパッケージデータベースを更新します。
$ wget -O - http://backports.org/debian/archive.key | apt-key add -
$ apt-get update
APT-Getでインストールします
apt-get install nginx
これは、ソースからコンパイルするよりもはるかに簡単です。
nginx confおよびサーバーファイルの構成
nginx.conf
user www-data;
worker_processes 4;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
client_body_temp_path /var/lib/nginx/body 1 2;
gzip_buffers 32 8k;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
tcp_nodelay on;
gzip on;
gzip_comp_level 6;
gzip_http_version 1.0;
gzip_min_length 0;
gzip_types text/html text/css image/x-icon
application/x-javascript application/javascript text/javascript application/atom+xml application/xml ;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
これで、Nginx仮想ホスティングを設定する必要があります。サイトを利用できるディレクトリのファイルにリンクされた各VホストSymを使用して、サイト対応の方法を使用するのが好きです。
$ mkdir /etc/nginx/sites-available
$ mkdir /etc/nginx/sites-enabled
$ touch /etc/nginx/sites-available/yourservername.conf
$ touch /etc/nginx/sites-available/default.conf
$ ln -s /etc/nginx/sites-available /etc/nginx/sites-enabled
$ nano /etc/nginx/sites-enabled/default.conf
default.conf
ノート:
次のファイルの静的キャッシュ設定は、Nginxプロキシキャッシュインテグレータープラグインが有効になっている場合にのみ機能します。
proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=staticfilecache:180m max_size=500m;
proxy_temp_path /var/lib/nginx/proxy;
proxy_connect_timeout 30;
proxy_read_timeout 120;
proxy_send_timeout 120;
#IMPORTANT - this sets the basic cache key that's used in the static file cache.
proxy_cache_key "$scheme://$host$request_uri";
upstream wordpressapache {
#The upstream apache server. You can have many of these and weight them accordingly,
#allowing nginx to function as a caching load balancer
server 127.0.0.1:8080 weight=1 fail_timeout=120s;
}
WordPressサイトconf (マルチサイトの場合、1つのvhostのみが必要です)
server {
#Only cache 200 responses, and for a default of 20 minutes.
proxy_cache_valid 200 20m;
#Listen to your public IP
listen 80;
#Probably not needed, as the proxy will pass back the host in "proxy_set_header"
server_name www.yoursite.com yoursite.com;
access_log /var/log/nginx/yoursite.proxied.log;
# "combined" matches apache's concept of "combined". Neat.
access_log /var/log/apache2/nginx-access.log combined;
# Set the real IP.
proxy_set_header X-Real-IP $remote_addr;
# Set the hostname
proxy_set_header Host $host;
#Set the forwarded-for header.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location / {
# If logged in, don't cache.
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
proxy_cache staticfilecache;
proxy_pass http://wordpressapache;
}
location ~* wp\-.*\.php|wp\-admin {
# Don't static file cache admin-looking things.
proxy_pass http://wordpressapache;
}
location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
# Cache static-looking files for 120 minutes, setting a 10 day expiry time in the HTTP header,
# whether logged in or not (may be too heavy-handed).
proxy_cache_valid 200 120m;
expires 864000;
proxy_pass http://wordpressapache;
proxy_cache staticfilecache;
}
location ~* \/[^\/]+\/(feed|\.xml)\/? {
# Cache RSS looking feeds for 45 minutes unless logged in.
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
proxy_cache_valid 200 45m;
proxy_cache staticfilecache;
proxy_pass http://wordpressapache;
}
location = /50x.html {
root /var/www/nginx-default;
}
# No access to .htaccess files.
location ~ /\.ht {
deny all;
}
}
セルフホストCDN conf
自己ホストのCDN confの場合、プロキシパスなしで静的ファイルを提供するために設定するだけが必要です
server {
proxy_cache_valid 200 20m;
listen 80;
server_name yourcdndomain.com;
access_log /srv/www/yourcdndomain.com/logs/access.log;
root /srv/www/yourcdndomain.com/public_html/;
proxy_set_header X-Real-IP $remote_addr;
location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
# Cache static-looking files for 120 minutes, setting a 10 day expiry time in the HTTP header,
# whether logged in or not (may be too heavy-handed).
proxy_cache_valid 200 120m;
expires 7776000;
proxy_cache staticfilecache;
}
location = /50x.html {
root /var/www/nginx-default;
}
# No access to .htaccess files.
location ~ /\.ht {
deny all;
}
}
次に、サーバーを起動します
$ /etc/init.d/apache2 restart
$/etc/init.d/nginx start
ベンチマークの結果
Apache Benchでは、このセットアップは理論的に1833.56秒のリクエストを提供できます
$ ab -n 1000 -c 20 http://yoursite.com/
マルチサイトに最小64MB RAMを備えたウェブスペースを使用し、APCを使用してApacheでmemcachedを使用します。 PageSpeedを使用してスキャンして、他のオプションも読み取り、テーマにコード化されています。キャッシュは素晴らしい作業を行うことができますが、悪いテーマやプラグインを修復することはできません。別の解決策は、WordPressのCDNとしてCookieなしでサブドメインを使用することです。これを、サブドメインではなく、ドメイン上のCookieの場合のWP-config.phpに追加します。
define( 'COOKIE_DOMAIN', 'example.com' );
次に、テーマのfunctions.phpに新しい関数を設定するか、プラグインを書き込み、パスフォームの静的コンテンツをサブドメインのカスタムCDNに置き換えます。
// replace for CDN on bloginfo
if ( !function_exists('fb_add_static_wpurl') ) {
function fb_add_static_wpurl($info, $show) {
if ( is_admin() )
return $info;
$keys = array(
'url',
'wpurl',
'stylesheet_url',
'stylesheet_directory',
'template_url',
'template_directory',
);
if ( in_array( $show, $keys ) ) {
$wpurl = get_bloginfo('wpurl');
$search = array(
$wpurl . '/wp-content/images/',
$wpurl . '/wp-content/download/',
$wpurl . '/wp-content/themes/',
$wpurl . '/wp-content/plugins/',
);
$replace = array(
'http://cdn1.example.com/',
'http://cdn2.example.com/',
'http://cdn3.example.com/',
'http://cdn4.example.com/',
);
return str_replace( $search, $replace, $info );
} else {
return $info;
}
}
add_filter( 'bloginfo_url', 'fb_add_static_wpurl', 9999, 2 );
}
これで、テンプレートとスタイルシートパスの関数
function fb_add_static_stylesheet_uri($uri) {
if ( is_admin() )
return $uri;
$wpurl = get_bloginfo('wpurl');
$search = array(
$wpurl . '/wp-content/images/',
$wpurl . '/wp-content/download/',
$wpurl . '/wp-content/themes/',
$wpurl . '/wp-content/plugins/',
);
$replace = array(
'http://cdn1.example.com/',
'http://cdn2.example.com/',
'http://cdn3.example.com/',
'http://cdn4.example.com/',
);
return str_replace( $search, $replace, $uri );
}
add_filter ( 'template_directory_uri', 'fb_add_static_stylesheet_uri' );
add_filter ( 'stylesheet_uri', 'fb_add_static_stylesheet_uri' );
add_filter ( 'stylesheet_directory_uri', 'fb_add_static_stylesheet_uri' );
ここで、Cookieなしでフロントエンドの静的CDN URLのページ速度を読み取ります。
また、ブロックの波状コンテンツのために.htaccessにフォローソースを追加します。
##
# Explicitly send a 404 header if a file on cdn[0-9].example.org is not
# found. This will prevent the start page (empty URL) from being loaded.
##
RewriteCond %{HTTP_HOST} ^cdn[0-9]\.example\.org [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* - [R=404,L]
##
# Do not dispatch dynamic resources via cdn[0-9].example.org.
##
RewriteCond %{HTTP_HOST} ^cdn[0-9]\.example\.org [NC]
RewriteCond %{REQUEST_FILENAME} \.(php|html)$
RewriteRule .* - [R=404,L]
この機能を使用してください。例でもあり、私のアイデアでソリューションを書くことができます。
Webサーバースタック
基本的にすべての操作をメモリに保ちます!
- モダンなCPU、高 メモリー 帯域幅WordPressは、主にメモリコピー、サブMSECディスクアクセス時間、UpCloudを試してください!
- 薄い仮想化レイヤー、アップクラウドを試してください!人気のない非エンテルプライズプロバイダーから遠ざけてください
- 高速オペレーティングシステム:SystemD、十分なエントロピー、IRQバランス、低メモリ使用量
- ブロックハンマー攻撃者:Fail2ban、永久にシャドウネットをブロックする
- Anycast DNS
- クイックウェブサーバー:ApacheイベントMPM
- RAMのような速度を備えた並列接続CDN(Amazon CloudFront)
- 高速SSL:ECDSA証明書、エントロピー源、TLS1.2、aes-Niのciphersuites、SSLセッションキャッシュ、OCSPステープリング、http/2
- FastCGIを介して接続されたOpcacheを使用した最新のPHP
- リーンワードプレスのインストール:最小限のプラグインのみ
- Redis Inmemoryオブジェクトキャッシュ
- tokudb(フラクタルツリー)Mariadbエンジン
- リソースの最適化
- JavaScriptsをカットします
- 連続監視:Pingdom、hetrixtools
私の知識はすべてオープンソースです https://github.com/szepeviktor/debian-server-tools