web-dev-qa-db-ja.com

WordPress / W3 Total CacheのMySQL、php-fpm、APC、Varnish、Nginxの最適化?

私は最初のVPSをセットアップしていますが、うまく機能しているようです。 Nginx、php-fpm(unixソケットとして)、APC、Varnish、MySQLをOnAppを備えたUbuntu 12.04サーバーにインストールすると、少なくとも私の側では、すべてが機能し、非常に高速です。

Atm iには、1コアのVPS(Xeon(R)X5660はVPSがiircを使用するものです)、1.2GHzおよび768MBのRAMがあり、すべてがOnAppで制限されています。 abテストを行って、私はこれを手に入れました:

ab -c 10 -n 1000 http://198.136.50.39/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.Apache.org/

Benchmarking 198.136.50.39 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        
Server Hostname:        198.136.50.39
Server Port:            80

Document Path:          /
Document Length:        6482 bytes

Concurrency Level:      10
Time taken for tests:   41.695 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      6952000 bytes
HTML transferred:       6482000 bytes
Requests per second:    23.98 [#/sec] (mean)
Time per request:       416.946 [ms] (mean)
Time per request:       41.695 [ms] (mean, across all concurrent requests)
Transfer rate:          162.83 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      167  203  57.3    182     614
Processing:   173  212  82.9    189    2015
Waiting:      169  206  59.8    185     726
Total:        345  415 126.5    373    2419

Percentage of the requests served within a certain time (ms)
  50%    373
  66%    388
  75%    410
  80%    430
  90%    504
  95%    708
  98%    866
  99%    931
 100%   2419 (longest request)

テストを行っている間、htopでVPSの統計を調べていましたが、テスト全体で230mb RAMを超えて使用されておらず、CPUは2〜4のままでした。使用率、かなりクールなものだと思いますが、1秒あたりのリクエスト数は少なかったようです。皆さんはどう思いますか?私が持っているセットアップには問題がなく、妄想的ですか、それとも悪いですか?デフォルトでは設定私はloadimpact.comを使用して調べました。25ユーザー(デフォルトの無料テスト)とデフォルトのロードは130ミリ秒です...設定をいじり始めた後、もう一度テストを行ったところ、250ミリ秒に跳ね上がったと思います。何か間違ったことをしている。

インターネットで見つけたローエンドボックス用のチュートリアルと https://tools.percona.com/ を使用して、MySQLを最適化しようと試み始めました。 Perconaは私にいくつかの本当に大きな数字をくれたので、私は両方を混ぜ合わせました。

また、php-fpmとNginxを最適化し、インターネット全体でwikiとチュートリアルを読みました。このVPSをWordPress Webサイトで1日あたり約5,000人の訪問者と13,000〜15,000回のページビューで使用します。W3TotalCacheは、APCを使用してデータベースとオブジェクトのキャッシュを実行し、ディスクが強化されました...しかし、サイトをこのサーバーに移行して稼働させる前に、すべてを最適化し、高速になることを確認したいと思います。

また、MaxCDN(VPS atmではアクティブではありません)を使用し、CloudFlareをDNSサーバーとして使用します。誰かが私がそれを最適化するのを手伝ってくれますか?

私のMySQL設定は次のatmのようになります:

[mysqld_safe]
open_files_limit = 8192

[mysqld]
skip_external_locking
skip_slave_start
bind-address        = 127.0.0.1
key_buffer      = 64M
join_buffer_size        = 1M
read_buffer_size        = 1M
sort_buffer_size        = 2M
max_allowed_packet  = 16M
max_connect_errors      = 10
thread_stack        = 192K
myisam-recover         = BACKUP
max_connections        = 400
table_cache            = 1024
thread_cache_size      = 286
interactive_timeout    = 25
wait_timeout           = 1000
query_cache_type    = 1
query_cache_limit   = 1M
query_cache_size        = 32M
max_write_lock_count = 1
expire_logs_days    = 10
max_binlog_size         = 100M

innodb_flush_method            = O_DIRECT
innodb_buffer_pool_size        = 10M

skip_name_resolve
sql_mode                       = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY

tmp_table_size      = 16M
max_heap_table_size = 16M

[mysqldump]
quick
quote-names
max_allowed_packet  = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer      = 16M

私のNginx設定は次のようになります:

worker_processes 1;

events {
    worker_connections 1024;
}

http {

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 15;
    types_hash_max_size 2048;
    server_tokens off;

    open_file_cache max=1000 inactive=300s;
    open_file_cache_valid 360s;
    open_file_cache_min_uses 2;
    open_file_cache_errors off;

        client_body_buffer_size 8K;
        client_header_buffer_size 1k;
        client_max_body_size 2m;
        large_client_header_buffers 2 1k;

        client_body_timeout   10;
        client_header_timeout 10;
        send_timeout          10;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";

    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 9;
    gzip_buffers 16 8k;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

私のサイトのNginx構成は次のようになります。

server {

    listen 8080;
    server_name www.ubuntubrsc.com ubuntubrsc.com;

    root /var/www;
    index index.php index.html index.htm;
        include /var/www/nginx.conf;

        error_log /var/log/nginx/blog.error_log;

        if ($Host ~* ^[^.]+\.[^.]+$) {
        rewrite ^(.*)$ http://www.$Host$1 permanent;
        }

    location / {
        try_files $uri $uri/ /index.php;
        }

        location = /favicon.ico {
    log_not_found off;
    access_log off;
        }

        location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
        }

        location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
        }

        location ~* ^/wp-content/uploads/.*.php$ {
    deny all;
    access_log off;
    log_not_found off;
        }

        rewrite /wp-admin$ $scheme://$Host$uri/ permanent;

        location ~ \.(css|js|htc)$ {
        root /var/www/ubuntu-online/;
        expires 31536000s;
        add_header Pragma "public";
        add_header Cache-Control "max-age=31536000, public, must-revalidate, proxy-revalidate";
        }
        location ~ \.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$ {
        root /var/www/ubuntu-online/;
        expires 3600s;
        add_header Pragma "public";
        add_header Cache-Control "max-age=3600, public, must-revalidate, proxy-revalidate";
        }
        location ~ \.(gif|gz|gzip|ico|jpg|jpeg|jpe|swf)$ {
        root /var/www/ubuntu-online/;
        expires 31536000s;
        add_header Pragma "public";
        add_header Cache-Control "max-age=31536000, public, must-revalidate, proxy-revalidate";
        }

    error_page 404 = @wordpress;
    log_not_found off;

    location @wordpress {
        include /etc/nginx/fastcgi_params;      
        fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_param SCRIPT_NAME /index.php;
            fastcgi_param SCRIPT_FILENAME $document_root/index.php;
        }

    location ~ \.php$ {
                try_files $uri =404;

        include /etc/nginx/fastcgi_params;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        if (-f $request_filename) {
                fastcgi_pass unix:/var/run/php5-fpm.sock;
            }
    }
      }

Ubuntu-onlineのキャッシュ部分は、W3 TotalCacheの設定が/ www/var /内のすべてのフォルダーで使用できるかどうかわからないため、「root/var/www/ubuntu-online /」のフォルダーを追加しました。承知しました。それらを消去する必要がありますか?

Php.iniで、open_basedirやその他のものなど、セキュリティを強化するためにいくつかのものを編集し、2行を編集するphp内部キャッシュを有効にしましたが、それが何であったかを思い出せません。

また、これらはAPC設定です。

[APC]
apc.enabled = 1
apc.cache_by_default = 1
apc.stat = 1
apc.shm_segments = 1
apc.shm_size = 64
apc.ttl = 7200

そして最後に、私のphp-fpmプール:

listen = /var/run/php5-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0666
pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

また、VarnishがWordPressで動作していることをどのように知ることができますか?私はニスを塗るためにいくつかの特定の設定をしなければならないことを知っています、そしてWP一緒にうまく遊ぶ、そして私はこれに従いました https://github.com/nicolargo/varnish-nginx-wordpress 、しかしどうすればそれが機能していることを知ることができますか?

上級者の皆さん、ありがとう(:

1

あなたはあなたの負荷のために非常に良いセットアップをしています。 20rpsからphpスクリプトは、毎日20万以上のページビューに十分です。

あなたのために調整するものは次のとおりです:innodb_buffer_pool_size = 10M-これはかなり小さな値です。 innodb内のすべてのアクティブなデータは、トランザクションログ用の十分なスペースを残して、バッファープールに収まる必要があります。

worker_connections 1024;-これはかなり早く使い果たされる可能性があります。スタブステータスモジュールを使用して実際の負荷でnginx接続を確認し、サービスが実行される最初の数日間を調整することをお勧めします。

Phpの同時実行性を増やすこともできますpm.max_children = 9-余分なRAMとCPUを利用する。完全なtcpバックログに問題がある場合はそれを行う(ss -nl

リクエスト率が高い場合やスクリプトが十分に遅い場合は、max_childrenの制限に達する可能性があります。スクリプトがCPUにバインドされている場合、最大作業スレッド/プロセスを増やすと、負荷平均が増加します。

基本的なおおよその数学をお見せしましょう。 100msで動作し、5msのCPU時間を使用するスクリプトがあります(100msはディスク/ネットワークIO待機)-平均して。

1秒あたり9 * 1000/100 = 90を超えるリクエストがある場合、tcpバックログは増加し始め、新しいリクエストは開始されるまでしばらく待機します。

スクリプトは、単一のCPUコアから90 * 10/1000 = 45%のCPUユーザー時間を消費します。そんなにないですよね?

Max_childrenを15に増やすと、速度を落とさずに1秒あたり150のリクエストが発生する可能性がありますが、スクリプトはシングルコアCPU時間の75%を消費する可能性があります。

負荷がかかりすぎるまでは問題ありません。選択した同時実行性で動作するのに十分なCPUまたはRAMがない場合-サーバーは負荷平均に達します-これは、CPUの輻輳が原因でスクリプトが遅くなることを意味します。負荷平均値が約2のサーバー-CPUコアカウントの4倍は通常、十分に応答します。リクエストの処理はやや遅くなりますが、より高いリクエストレートを処理できます。十分な数がない場合RAM-サーバーはスワッピング、ロードを開始しますディスクとスロットリングCPU。

したがって、max_childrenが少なすぎる-高い要求率を処理できません。多すぎる-そしてあなたのサーバーは高負荷の下でハングします。

2
DukeLion