11月 25

Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx(もしくはApache)に分けてproxy cacheを効かせるのが王道です。
さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。

今回はそこからもう一歩進めたチューニングについて書きたいと思います。

二段階層を廃したシンプルな構成

まずは、図をご覧ください。

構成図

前述の王道チューニングの構成はA図となります。

proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。
A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表しています。
A図-3は静的なファイル(css, js, jpgなど)をフロントのNginxが直接返すことを表しています。

fastcgi cache(HttpFcgiModule)

proxy cache自体はバックエンドのサーバーがHTTPでコンテンツを返してくれれば、どんなアプリケーションでも問わない汎用的なキャッシュ機能です。つまり、proxy cacheを利用しようとするともうひとつHTTPサーバーが必要になり、A図のようにHTTPのレイヤーが二段構成になります。

Nginxにはproxy cacheと似た機能でfastcgi cacheという機能(HttpFcgiModule)があります。これはバックエンドのFastCGIのレスポンスをキャッシュする機能です。
これを利用すると、proxy cacheを利用したのと同じ効果をHTTPサーバーなしに実現できます。
A図の8080ポートのサーバーが必要なくなり、B図の構成になります。
無駄な通信と処理がなくなり、シンプルです。

WP Super Cacheを最大限利用する

WP Super Cacheは、アクセスごとに動的に生成される記事を、静的なHTMLファイルとして保存(キャッシュ)して、それを返すように振舞うプラグインです。
キャッシュが効いている間はMySQLにアクセスすることが無いのでパフォーマンスが上がります。

.htacessの落とし穴

WP Super Cacheを利用すると、.htaccessに以下の設定が追加されます。
(利用しているプラグインによって多少変わります)

# BEGIN WPSuperCache

RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC]
RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC]
RewriteCond %{HTTP_USER_AGENT} !^(DoCoMo/|J-PHONE/|J-EMULATOR/|Vodafone/|MOT(EMULATOR)?-|SoftBank/|[VS]emulator/|KDDI-|UP\.Browser/|emobile/|Huawei/|IAC/|Nokia|mixi-mobile-converter/)
RewriteCond %{HTTP_USER_AGENT} !(DDIPOCKET;|WILLCOM;|Opera\ Mini|Opera\ Mobi|PalmOS|Windows\ CE;|PDA;\ SL-|PlayStation\ Portable;|SONY/COM|Nitro|Nintendo)
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).* [NC]
RewriteCond %{HTTP_user_agent} !^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).* [NC]
RewriteCond %{HTTP_USER_AGENT} !^(DoCoMo/|J-PHONE/|J-EMULATOR/|Vodafone/|MOT(EMULATOR)?-|SoftBank/|[VS]emulator/|KDDI-|UP\.Browser/|emobile/|Huawei/|IAC/|Nokia|mixi-mobile-converter/)
RewriteCond %{HTTP_USER_AGENT} !(DDIPOCKET;|WILLCOM;|Opera\ Mini|Opera\ Mobi|PalmOS|Windows\ CE;|PDA;\ SL-|PlayStation\ Portable;|SONY/COM|Nitro|Nintendo)
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html" [L]


# END WPSuperCache

これは、すでにWP Super Cacheによって静的なファイルが生成されている場合、PHPを介さずにApacheが直接リクエストを返すようにする設定です。
WP Super Cacheの推奨設定では、index.htmlとそれを圧縮したindex.html.gzが用意されるので、冗長な設定になっています。

Nginxにとって.htaccessはただのテキストファイルですから、上記RewriteRuleをNginxの設定ファイルに移植しないと、WP Super Cacheは本来のパフォーマンスを発揮しません。
この移植をすることで、B図-4のように、fastcgi cacheに到達することもなく、静的ファイルと同じ処理、パフォーマンスになります。

HttpGzipStaticModule

NginxのHttpGzipStaticModuleは、同じディレクトリ内にあらかじめ圧縮ファイル(.gz)が用意されている場合に、クライアント判定を行なって自動的に圧縮ファイルを返してくれるモジュールです。(正確には、Gzip圧縮に対応しているクライアントからリクエストが来て、同ディレクトリに同タイムスタンプで同名+.gzという名前のファイルがある場合)

このモジュールを導入するメリットは、gzファイル分の.htaccessを移植する手間がなくなることです。ただし、コアモジュールではないので、コンパイル時にオプションで指定する必要があります。

./configure --with-http_gzip_static_module

コンパイルし直したnginxの入れ替えを行う場合は、こちらを参考にしてください。

NginxにはコアモジュールでHttpGzipModuleがあり、設定をオンにすることで特定のContent-TypeにGzip圧縮をかけてレスポンスを返すことができます。こちらはリクエストごとにオンザフライで圧縮をかけるので、余分に処理がかかります。あらかじめcssやjsなどの圧縮ファイルが用意できる場合は、同階層に設置してHttpGzipStaticModuleの恩恵を受けたほうがいいと思います。

サンプル設定ファイル

前述の項目を網羅して、かつ可能な限り正常に動いている環境の設定ファイルを載せています。

nginx.conf

user  nginx nginx;
worker_processes  2; # サーバーのコア数に合わせて

pid  /var/run/nginx.pid;

events {
    worker_connections  1024;
    use epoll; # Linuxの場合
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    # 最後の$request_timeは処理時間(ms)
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" $request_time';

    sendfile        on;
    tcp_nopush     on;
    tcp_nodelay on;

    keepalive_timeout  10;

    connection_pool_size 256;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 2k;
    request_pool_size 4k;
    if_modified_since before;
    ignore_invalid_headers on;
    server_tokens off;

    gzip  on;
    gzip_min_length 0;
    gzip_buffers 4 8k;
    gzip_types text/plain text/xml application/x-javascript text/css;
    gzip_disable "msie6";
    gzip_vary on;
    # HttpStaticGzipModuleをオンに
    gzip_static on;

    output_buffers 1 32k;
    postpone_output 1460;

    # fastcgi cacheの設定(httpディレクティブ内のみ有効)
    fastcgi_cache_path      /usr/local/nginx/cache levels=1:2 keys_zone=wpcache:10m max_size=50M inactive=30m;

    server {
        listen       80;
        server_name  localhost;
        charset utf-8;

        location / {
            return 403;
        }

        location /nginx_status {
            stub_status on;
            access_log off;
            allow 127.0.0.1;
            deny all;
        }  

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }

    include ./wordpress.conf;
}

wordpress.conf

# 設定を変えやすいようにupstreamにまとめておく
upstream phpfpm {
    # ローカルの場合はUNIXソケットで
    server unix:/var/run/php-fpm/www.sock;
}

server {
    listen       80;
    server_name  example.com;
    root /var/www/wordpress;
    access_log logs/access.log main;

    location / {
        # 静的なファイルの場合は処理をとめる
        # リクエストの度にファイルの存在をチェックするのは無駄だという意見もありますが、
        # どのURLの時index.phpに渡すのか、プラグインを含めて全仕様が分からないため、
        # これが最も安全だと思います。
        if (-f $request_filename) {
            break;
        }

        # ここからWP Super Cacheの設定(少しfastcgi cacheの設定も)
        # モバイルからのアクセスはキャッシュさせないようにする変数
        set $nocache "";
        set $supercache_file $document_root/wp-content/cache/supercache/${http_host}${uri}/index.html;
        set $supercache_uri "";
        if (-f $supercache_file) {
            set $supercache_uri /wp-content/cache/supercache/${http_host}${uri}/index.html;
        }

        if ($request_method = "POST") {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($query_string ~ .*=.*) {
            set $supercache_uri "";
        }

        if ($http_cookie ~ ^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_x_wap_profile ~ ^[a-z0-9\"]+) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_profile ~ ^[a-z0-9\"]+) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_user_agent ~ ^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).*) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_user_agent ~ ^(w3c\ |w3c-|acs-|alav|alca|amoi|audi|avan|benq|bird|blac|blaz|brew|cell|cldc|cmd-|dang|doco|eric|hipt|htc_|inno|ipaq|ipod|jigs|kddi|keji|leno|lg-c|lg-d|lg-g|lge-|lg/u|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|nec-|newt|noki|palm|pana|pant|phil|play|port|prox|qwap|sage|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|tsm-|upg1|upsi|vk-v|voda|wap-|wapa|wapi|wapp|wapr|webc|winw|winw|xda\ |xda-).*) {
            set $supercache_uri "";        
            set $nocache "1";
        }

        if ($http_user_agent ~ ^(DoCoMo/|J-PHONE/|J-EMULATOR/|Vodafone/|MOT(EMULATOR)?-|SoftBank/|[VS]emulator/|KDDI-|UP\.Browser/|emobile/|Huawei/|IAC/|Nokia|mixi-mobile-converter/)) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($http_user_agent ~ (DDIPOCKET\;|WILLCOM\;|Opera\ Mini|Opera\ Mobi|PalmOS|Windows\ CE\;|PDA\;\ SL-|PlayStation\ Portable\;|SONY/COM|Nitro|Nintendo)) {
            set $supercache_uri "";
            set $nocache "1";
        }

        if ($supercache_uri) {
            rewrite ^ $supercache_uri last;
            break;
        }

        rewrite ^ /index.php last;
    }

    location ~ \.php {
        # 存在しないPHPファイルをシャットアウト
        if (!-f $request_filename) {
            return 404;
            break;
        }

        # fastcgi とfastcgi cacheの設定
        include ./fastcgi.conf;
        fastcgi_pass          phpfpm;
        fastcgi_cache         wpcache;
        fastcgi_cache_key     "$scheme://$host$request_uri";
        fastcgi_cache_valid   200 10m;
        fastcgi_cache_valid   404 1m;
        # $nocache = "1"の時、fastcgi cacheが無効になる
        fastcgi_cache_bypass  $nocache;
    }

    # よくアクセスされる静的ファイルにブラウザキャッシュが効くように設定
    location ~ \.(jpg|png|gif|swf|jpeg)$ {
        log_not_found off; # 404の時にerror_logに書き込まないようにする設定
        access_log off;
        expires 3d;
    }

    location ~ \.ico$ {
        log_not_found off;
        access_log off;
        expires max;
    }

    location ~ \.(css|js)$ {
        charset  UTF-8;
        access_log off;
        expires 1d;
    }

    # ドット始まりのファイルはアクセスできないように
    location ~ /\. {
        deny all;
        log_not_found off;
        access_log off;
    }

    # リライトされたWP Super Cacheのファイル
    location ~ /wp-content/cache/supercache/${http_host}${uri}/index\.html(\.gz)?$ {
        charset  UTF-8;
        internal; # この指定をしておくとURLを指定して直接アクセスできなくなる
    }

    location ~ /wp-admin/$ {
        rewrite ^/wp-admin/$ /wp-admin/index.php last;
    }
}

処理の解説

Nginxのlocationディレクティブの評価順番は、wordpress.confを例にとると、すべてのアクセスが最初に “location /”ディレクティブを通ります。(記述順番は関係ありません。)

静的ファイルのチェック

このディレクティブの先頭でリクエストされた静的ファイルが存在するかのチェックを行なっています。
静的ファイルとして存在した場合、breakで”location /”ディレクティブの処理が終わります。次に、マッチするlocationディレクティブがあればそちらが実行されます。
例えば、cssファイルだった場合は、”location ~ \.(css|js)$”ディレクティブへ処理が続いていきます。これがB図-3の流れです。

WP Super Cacheのチェック、fastcti cacheのチェック

静的ファイルとして存在しなかった場合、処理は下へ進みます。
次の処理ではWP Super Cacheが生成したキャッシュファイルの存在をチェックし、キャッシュファイルを利用するかどうかを下に続く条件で確認していきます。各条件では同時にfastcgi cacheを利用するかどうかのチェックも行なっています。

ここでは、$supercache_uriが””(空文字)に書き換えられると、WP Super Cacheの静的キャッシュファイルが使われず(下の判定で利用されます)、$nocacheが”1″に書き換えられると、fastcgi cacheが使われません( ~ \.phpディレクティブで利用されます)。

$supercache_fileが存在し、$supercache_uriが空でない場合は、”location ~ /wp-content/cache/supercache/${http_host}${uri}/index\.html(\.gz)?$”ディレクティブへ処理が続きます。これがB図-4の流れです。

全てを受け止めるindex.php

静的ファイルのチェック、WP Super Cacheのチェックが終わっても処理が続く場合は、すべてにリクエストがindex.phpへと渡され、”location ~ \.php”ディレクティブへ処理が続きます。
すでにキャッシュされていて期限が有効な場合は、fastcgi cacheが使われ(B図-2)、キャッシュがなかったり、期限が切れていた場合は、FastCGI(PHP)へ処理が渡されます(B図-1)

今回はステータスコード200の時は10分、404の時は1分キャッシュするように設定してあります。

404がキャッシュされない

目に見える記事部分のキャッシュが効いて応答が良くなると忘れてしまいがちですが、WordPressが返す404 Not Foundは無視できないくらい重い処理です。
404に対してキャッシュが作られないと、存在しない記事にアクセスがくる度にPHPとMySQLが仕事をしてしまいます。

そこで、fastcgi cacheの設定で “fastcgi_cache_valid 404 1m;” を指定しているわけですが、そのままだとキャッシュが効ききません(WordPress 3.2.1)。
調べてみると、WordPressは404の時、ヘッダーに “Cache-Control:no-cache, must-revalidate, max-age=0″ を付けてレスポンスを返すことがわかりました。
このヘッダーがあるのでfastcgi cacheはキャッシュを作らないようなのです。

もっとスマートな方法があると思いますが、今回はWordPressのソースを少しいじって対応することにしました。

wp-includes/class-wp.php

function handle_404() {
    global $wp_query;

    if ( !is_admin() && ( 0 == count( $wp_query->posts ) ) && !is_404() && !is_robots() && !is_search() && !is_home() ) {
        // Don't 404 for these queries if they matched an object.
        if ( ( is_tag() || is_category() || is_tax() || is_author() || is_post_type_archive() ) && $wp_query->get_queried_object() && !is_paged() ) {
            if ( !is_404() )
                status_header( 200 );
            return;
        }
        $wp_query->set_404();
        status_header( 404 );
        //nocache_headers(); # ここをコメントアウト
    } elseif ( !is_404() ) {
        status_header( 200 );
    }
}

これで404もキャッシュされるようになりました。

おわりに

WordCamp Tokyo 2011弊社はWordPessのイベント、WordCamp 2011 Tokyoに微力ながらスポンサーとして協力させて頂きました。

ブログにもWordPressの記事が少なく、弊社がWordPressにコミットしている感じが伝わっていないと思ったので、開催前に何とか間に合って良かったです。

参考サイト

28 Responses to “Nginxを使ったもう一歩進んだWordPressチューニング”

  1. […] Nginxを使ったもう一歩進んだWordPressチューニング […]

  2. Leonard より:

    Your website’s template looks crappy. You schould change it.
    Better design means more conversions, faster load and
    greater confidence of visitors. This is something that can be useful for you, search in google:
    Juicklor’s templates source

  3. […] 用しています。 このサイトの絵がわかりやすいですね […]

  4. […] Nginxを使ったもう一歩進んだWordPressチューニング […]

  5. […] 「Nginxを使ったもう一歩進んだWordPressチューニング」を見て知ったのだが、NginxにはFast CGI Cacheという機能がある。これは名前の通りCGIの処理結果をキャッシュするものである。今まではS […]

  6. […] Nginxを使ったもう一歩進んだWordPressチューニング […]

  7. […] Nginxを使ったもう一歩進んだWordPressチューニング […]

  8. […] WordPressをNginxで運用 – WP Super Cacheで高速化 Leave a reply Apacheよりも負荷に強く、軽量なNginxでWordpressを当サイトを運用しています。 最近、高速化をしてみようと思い、『WP Super Cache』のプラグインを導入しました。 Nginxを使ったもう一歩進んだWordPressチューニングを参考に設定しました。いろいろと書いてあって、最初は辛そうに感じましたが、案外あっさりと設定できました。 […]

  9. […] Nginxを使ったもう一歩進んだWordPressチューニング   cloudrop.htmx  […]

  10. […] Nginxを使ったもう一歩進んだWordPressチューニング   cloudrop.htmx  […]

  11. […] Nginxを使ったもう一歩進んだWordPressチューニング   cloudrop.htmx […]

  12. […] Nginxを使ったもう一歩進んだWordPressチューニング   cloudrop.htmx […]

  13. […] cloudrop – Nginxを使ったもう一歩進んだWordPressチューニング […]

  14. […] cloudrop – Nginxを使ったもう一歩進んだWordPressチューニング […]

  15. […] FastCGIではなくPHP-FPMを選んだのはNginxを使ったもう一歩進んだWordPressチューニングという記事を見たからです。 というワケで、このサイトを参考にnginx.confを設定(コピペ)してサーバーの […]

  16. […] FastCGIではなくPHP-FPMを選んだのはNginxを使ったもう一歩進んだWordPressチューニングという記事を見たからです。 というワケで、このサイトを参考にnginx.confを設定(コピペ)してサーバーの […]

  17. […] まぁ原因はコピペしただけで済ませたconfであるのは判明しているのですが(※参考サイトの情報に間違いがあるワケではありません)、どこをどう弄っていいのやら。 WP SuperCache関連の […]

  18. […] FastCGIではなくPHP-FPMを選んだのはNginxを使ったもう一歩進んだWordPressチューニングという記事を見たからです。 というワケで、このサイトを参考にnginx.confを設定(コピペ)してサーバーの […]

  19. […] ・CentOSでnginxリバースプロクシとWordpressのブログを立ち上げる手順 ・さくらのVPS サーバ構築メモ ・Nginxを使ったもう一歩進んだWordPressチューニング […]

  20. […] ・CentOSでnginxリバースプロクシとWordpressのブログを立ち上げる手順 ・さくらのVPS サーバ構築メモ ・Nginxを使ったもう一歩進んだWordPressチューニング […]

  21. […] ・CentOSでnginxリバースプロクシとWordpressのブログを立ち上げる手順 ・さくらのVPS サーバ構築メモ ・Nginxを使ったもう一歩進んだWordPressチューニング […]

  22. […] Nginxを使ったもう一歩進んだWordPressチューニングを参考にしました。まぁ、そこの設定ファイルは、マルチサイト用じゃないけど。 […]

  23. ysakaki より:

    参考として性能比較が欲しいです!後、コメントしようとしたらopenidベースのコメントは404エラーになりました。

  24. […] Nginxを使ったもう一歩進んだWordPressチューニング […]

  25. […] MySQLの調整やnginx proxy cache | KRAY Inc ■Nginxを使ったもう一歩進んだWordPressチューニング | cloudrop […]

  26. […] Nginxを使ったもう一歩進んだWordPressチューニング | cloudrop […]

コメントを残す

通常のコメント欄に切り換え

アカウントを持っているサービスをクリックしてください。

preload preload preload