百万ワードプレスの訪問者対サーバー

私のサーバーは、その後のストーリーテリングのヒーローになりますが、DualCore Xeon E3110 3.00Ghzプロセッサーを搭載したFirstDedicからレンタルされた通常のミドルクラスのサーバーです。 RAMは4 GB、500 GBのハードドライブにインストールされました。 サーバーには、nginx 1.01がフロントエンドとしてインストールされ、apache 2がバックエンドとしてインストールされ、スクリプトはCGIモードで実行されていました。



話は私のサーバーに投稿されたサイトで起こりました。実際は、サイトではなく、 誰かの個人的なブログです。 以前のブログでは、1日あたり最大10,000のトラフィックのピークが観察されましたが、サーバーは標準の構成ファイルを最適化することなく、この負荷にすばやく対応しました。



そのため、朝のすばらしい「女性の日」、SMSは、サーバーが利用できないサイト監視サービスから送信されます。 当然、そのようなニュースからすぐに目を覚まし、サーバーにpingを試みます。 Pingは存在しましたが、非常に無気力でした。 すべてのサーバーリソースが不明なプロセスに割り当てられているため、SSH接続を確立できません。



KVM経由で接続して、サーバーを再起動するように送信し、起動直後にSSH経由で接続しました。 そのプロセスで、私はひどい絵を見ました：ブログの作者に代わって約1000のphpプロセスが起動され、さらに、平均負荷は100以上です。 プロセスがリソースの一部に対して順番にどれだけ期待しなければならないかを示す非常に恐ろしい指標。



当然、topコマンドを実行してこれを確認するのに十分な時間しかありませんでした。 1分以内にサーバーが応答しなくなり、サーバーを再起動しなければならず、再起動後すぐにApacheをオフにしました。 これで、すべてのリソースを消費しないサーバーを確実に取得できます。 分析を開始し、netstatコマンドを使用して開いている接続の数を推測しました。 nginxとの接続が10,000以上確立されました。 これは、最後の1分間にクライアントのサイトへの1万回の試行があったことを意味します-良い負荷です。



当然、クライアントの同意を得て、WordPressの設定を調べてみたところ、WP Super Cacheキャッシングプラグインがアクティブになっていることがわかりました。 プラグインをオフにすると、サイトはデータベースに対して多くのクエリを実行し始めました-当然のことです。 したがって、最初に行ったのはMySQLのクエリキャッシングシステムをオンにすることでした。これは、多くの遷移があった1つのページのみによって負荷が与えられたためです。 クエリキャッシングを有効にした後、データベースはより自由にため息をつきましたが、主な負荷がWordpress自体によって与えられたという事実にもかかわらず、私たちが望むほどではありませんでした。



考えられるすべてのプラグインをオフにし、リクエストの数を最小限にしてトピックを書き換えても、負荷は減少しませんでした。 私は極端な対策を講じなければなりませんでした-nginxでプロキシされたリクエストの強制キャッシュを有効にしました。 これを行うには、httpセクションに次の行を入力しました

proxy_cache_path /path/to/cache levels=1:2 keys_zone=wpblog:10m max_size=10m;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

必要なサーバーセクションで、次のように記述します。

 proxy_cache_valid 200 3m; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを行うとすぐに、サーバーの負荷が急激に低下しました。 ただし、管理とコメントに関連する多くの不便がありました。 不便にも関わらず、問題は解決されました。 ただし、このようなキャッシュを手動で有効にすることは必ずしも時間と機会ではないことを意識していましたが、そのままにしておくことはブログの著者の選択肢ではありませんでした。 したがって、承認されたユーザーとコメントを残したユーザーのキャッシュを禁止する必要がありました。 結果は、おおよそ次のサーバーセクションです。

 proxy_cache_valid 200 3m; location / { if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) { set $do_not_cache 1; } proxy_no_cache $do_not_cache; proxy_cache_bypass $do_not_cache; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080; } location ~* wp\-.*\.php|wp\-admin { proxy_pass http://127.0.0.1:8080; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ { root /path/to/static; access_log off; expires max; add_header Last-Modified: $date_gmt; } location ~* \/[^\/]+\/(feed|\.xml)\/? { proxy_pass http://127.0.0.1:8080; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この後、作業の不便さは継続性によって完全に補償されます。



上記のすべての結果として、サーバーは2時間利用できませんでしたが、この間にトラフィックフローは大幅に減少しましたが、この事件の後、サーバーに顕著な負荷を与えることなくサイトが正常に耐えた他の同様の休日のトラフィックスパイクがありました。 それ以来、ホストされているすべてのWordPressサイトにこのような構成を配置しようとしています。



クライアントのサイトのGoogleアナリティクスは、サーバーが最終的に稼働した後、6,000人の訪問者をオンラインで表示しました。 サイトがすべての検索エンジンの上位にあったリ​​クエストの関連性が毎分失われたため、この数字は急速に減少しました。 一日の終わりには、訪問者の数は7桁になりましたが、リソースの所有者は私をオオカミと見なしています。



この設定を使用すると、サーバーがそのようなサイトをいくつか転送すると自信を持って言えます。 Google Newsに追加した後の私のプロジェクトは、実際にはYandexブログで多くのトラフィックを集め始めました。