Apacheを10K以上に最適化wordpress 2GBで1日の視聴回数RAM E6500 CPU
私はWordpressブログを1日約10K +ページビューで提供しているUbuntuでApache/phpを備えた専用サーバーを持っています。APCにW3TCプラグインがインストールされています。
しかし、時々サーバーが応答を停止するか、非常に遅くなり、それを元に戻すにはApacheを再起動する必要があります。
私の設定は何ですか？
ServerRoot "/etc/Apache2"
LockFile /var/lock/Apache2/accept.lock
PidFile ${Apache_PID_FILE}
TimeOut 40
KeepAlive on
MaxKeepAliveRequests 200
KeepAliveTimeout 2
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 8
ServerLimit 80
MaxClients 80
MaxRequestsPerChild 1000
</IfModule>
<IfModule mpm_worker_module>
StartServers 3
MinSpareServers 3
MaxSpareServers 3
ServerLimit 80
MaxClients 80
MaxRequestsPerChild 1000
</IfModule>
<IfModule mpm_event_module>
StartServers 3
MinSpareServers 3
MaxSpareServers 3
ServerLimit 80
MaxClients 80
MaxRequestsPerChild 1000
</IfModule>
User ${Apache_RUN_USER}
Group ${Apache_RUN_GROUP}
AccessFileName .htaccess
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy all
</Files>
DefaultType text/plain
HostnameLookups Off
ErrorLog /var/log/Apache2/error.log
LogLevel error
Include /etc/Apache2/mods-enabled/*.load
Include /etc/Apache2/mods-enabled/*.conf
Include /etc/Apache2/httpd.conf
Include /etc/Apache2/ports.conf
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /var/log/Apache2/other_vhosts_access.log vhost_combined
Include /etc/Apache2/conf.d/
Include /etc/Apache2/sites-enabled/
私のWordPressパフォーマンスとキャッシュスタック
これはすばらしいWordPress低/中範囲の単一サーバーまたはVPSのパフォーマンススタックです。私は、中範囲を約1Gのメモリとかなり高速のドライブを備えた単一コアとして分類しています。
あなたのボックスでは、これは1時間あたり10000以上のページビューを提供することができます
サーバースタック
- Linux-Debian LennyまたはUbuntu
- Nginx-リバースプロキシの静的ファイルキャッシュとして構成
- Apache-ApacheはNginxによって代替ポートでオフロードされるPHP=を処理します
- MySql-WPで必要です。最新の安定バージョンを実行していることを確認してください
- PHP-5.2または5.3ブランチの最新の安定バージョン
PHPキャッシュ
- APC-mmapメモリーと128M以上のshmサイズで構成します
WordPressパフォーマンスプラグインスタック
- Nginxプロキシキャッシュインテグレーター
- W3合計キャッシュ -ページキャッシュをディスクに設定し、ディスクに縮小し、オブジェクトとデータベースをAPCに設定します。
- Self Hosted CDN-静的ファイルを提供するためだけに設定されたサーバー上のドメインを指す4つのcnameエイリアスを作成します
W3 Total Cacheでは、Nginxが静的ファイルを非常に高速に提供するため、ページキャッシュとミニファイにディスクを使用しています。
Nginxを設定して静的ファイルを提供し、PHP= Apacheに渡す方法
Apacheを単独で使用する場合の問題は、接続が開かれ、静的ファイルであってもすべてのリクエストでphpにヒットすることです。これは、Apacheが接続を開いたままにし、大量のトラフィックがある場合、接続が使用されていなくても接続が停止するため、接続を無駄にします。
デフォルトでは、ApacheはデフォルトのWebポートであるポート80で要求を待機します。まず、Apache confファイルと仮想ホストファイルを変更して、ポート8080でリッスンします。
Apache設定
httpd.conf
keepAliveをオフに設定します
ports.conf
NameVirtualHost *:8080
Listen 8080
サイトごとの仮想ホスト
<VirtualHost 127.0.0.1:8080>
ServerAdmin [email protected]
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設定
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仮想ホスティングをセットアップする必要があります。私は、sites-enabledメソッドを使用して、各v Host symをsites-availableディレクトリー内のファイルにリンクします。
$ 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;
}
Per WordPress site conf（マルチサイトの場合、必要な仮想ホストは1つだけです）
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構成
自己ホスト型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では、この設定は理論的には1秒あたり1833.56リクエストを処理できます
$ ab -n 1000 -c 20 http://yoursite.com/
これは標準のApache構成のように見えますが、HTMLのように見えるため一部が削除されているようです。
サーバーの応答が遅いときに何が起こっているのかを調査する必要があります。あなたはあなたのサーバーのスペックを言っていませんが、あなたはそのサーバーに言及しており、1日あたり10000kは簡単に処理されるはずです。
- トップには何が表示されますか？
- ボトルネックはどこですか？ CPU、メモリ、I/O待機？
- Apacheプロセスはいくつ実行されていますか？
- Netstatに表示される接続の数は？
おそらく、CPUはおそらくPHPが原因のボトルネックです。 APCとWPキャッシングプラグインは、これを軽減するための優れた方法であり、すでに行っています。「Prefork」の代わりにApacheの「MPM」プロセスモデルを試すこともできます。確認してください。 PHPスクリプトをキャッシュし、「ミス」しないようにするために、APCに十分なメモリが割り当てられている。
MySQLである可能性もあります-それがCPUやディスクを使い果たしているかどうかを確認してください。
Mod_deflateを有効にしている場合は、オフにすることを検討してください。ロード時間は短縮されますが、CPUの負荷が増える可能性があります。試してみる価値があるかもしれません。
「siege」や「ab」などのツールを使用してサーバーのベンチマークを行い、サーバーの速度が低下する時点を特定します。
これが、Webサーバーパフォーマンスチューニングのブックマークの一部です。 http://articles.slicehost.com/2010/5/19/configuring-the-Apache-mpm-on-ubunt
http://www.devside.net/articles/Apache-performance-tuning
http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/
しかし、私の最初のアドバイスは同じままです-ボトルネックが最初に何であるかを見つけてください！それ以外の場合は、盲目的にパフォーマンスを改善しようとしています（確かに、パフォーマンスを改善することは常に良いことです）。
server-status モジュールを有効にして、そこにアクセスし、何が起こっているかを確認してください。
交換している可能性があります。これが起こっている間にvmstatをチェックアウトしましたか？ 2GBのRAMは、それぞれ25 MBです（ボックスが他に何も実行していない場合）。MaxClientsが高すぎる可能性があります。これに対する解決策は明らかです：さらに追加= RAM以下のMaxClients。Apacheの再起動時にコマンドラインの応答が遅い場合、これはこの状況の1つの兆候です。
また、一部のモバイルクライアント（または低速接続のその他のクライアント）に「大きな」ファイルをスプーンで供給して、利用可能なすべてのApacheスロットを消費している可能性もあります。 MaxClientsが少なすぎるかもしれません。 server-statusを確認すると、それらの各クライアントがその時点で何をしているかがわかります。この状況の1つの解決策は、MaxClientsを増やすことです（ただし、上記の状況になる可能性もあります）。これに対するより良い解決策は、Apacheの前にHTTPアクセラレータをインストールすることです（1つの無料オプションはperlbalです）。コマンドラインが正常な場合Apacheを再起動するときの速度は、この状況の1つの兆候です。
mod_status を使用すると、複数のApacheインスタンスの内部で何が行われているのかを確認できますが、実際にはパフォーマンスが低下することに注意してください。それはメモリを消費するようで、1つのケースでは、何も直接提供されないリバースプロキシのみの設定で単一プロセスのロックアップの原因であるかどうかを診断できませんでした。もちろん、これらは「ページをロードするのに永遠にかかる」とユーザーから報告されています。彼らは通常、数秒（<10）秒後にブラウザでStopを押すため、「待つのにさらに10秒かかった」と「終了しない」の違いさえ理解していません。
また、正しい場所を構成しているかどうかを確認します（インスタンス/プロセスの数が表示されるため、mod_statusを使用すると簡単に確認できます）。少なくともubuntuでのストック構成には、MPMモードごとにifdefされたセクションがあり、プリフォークを実行しているときにワーカーモードを編集するのは簡単です（PHPスレッドセーフではありません）。
ああ、そして何よりも：ルートとして atop を実行し、リソースの最大化に注意してください。メモリ、ディスク、CPU-表示されます。
もう1つ：mod_deflateを非アクティブ化するという考えは、設定が誤ったContent-Length情報のエラーになりがちではありませんが、ブラウザーがデータを「永久に」待機して、「非常に遅い」「応答しない」というレポートを与える可能性はありません。
ところで、1日あたり10Kの配信ページとこのマシンのメディアファイルは、すべてが1時間以内にアクセスする場合にのみ問題になります。
特に多くのメディアファイルをホストする場合のアドバイス：
- メディアを専用のApache（またはそれ以上：nginx）インスタンスに移動します。 PHPなし、モジュールなし、メディアを可能な限り高速で配信する裸のhttpサーバーのみ。
- キャッシュ、キャッシュ、キャッシュ！ワードプレスのスーパーキャッシュプラグインを使用します。それは非常に役立ちます。
- ヘッダーのApache構成を確認してください。画像およびその他の「安定した」メディアの有効期限が遠い日付に設定されていること、およびクライアントから要求されたときにApacheがHTTP 304コードを返すことを確認します
- Mod_deflateを有効にします。クライアントのパフォーマンスが低下する可能性がありますが、より速く提供されます。