Ubuntu 16.04でFirefox、Siege、Sproxyを使用してWebサイトをベンチマークする方法
序章
Siege は、Webページを要求することによってWebサーバーをテストするWebサイト用の構成可能なベンチマークおよびテストツールです。 Siegeが要求する1秒あたりのページ数は、1秒あたり数ページから、Webサイトが処理できる最大数までの任意のページに設定できます。
この情報は、どのサーバーリソースが最初に使い果たされ、どのトラフィックレベルで消費されているかを強調することにより、パフォーマンスのボトルネックを発見するのに非常に役立ちます。 この情報を利用して、ライブサイトに障害が発生する前に、サーバーの構成を変更したり、サーバーのハードウェアをアップグレードしたりできます。 さらに、バックアップなどの一般的なシステム管理手順をシミュレートされた負荷の下でテストして、Webサイトのパフォーマンスへの影響を判断できます。
このガイドでは、ベンチマークモードとブラウジングモードで実行するようにSiegeをインストールして構成します。 ベンチマークモードは、Webサーバーが処理できる限り多くの要求を行い、ブラウジングモードは、Webサイトへの構成可能な訪問者数をシミュレートします。
Firefoxを使用すると、プロキシサーバーを介して実行されるインターネット接続の構成が特に簡単になるため、これを使用してSproxyプロキシサーバーを介してインターネットに接続します。 Siegeと連携するために特別に作成されたSproxyは、Siegeを通過するすべてのリクエストのURLをファイルに記録します。 そのファイルを使用して、テストするURLをSiegeに通知します。
このチュートリアルの最初の部分では、Sproxyをインストールし、それを介してインターネットに接続するようにFirefoxを構成します。 そこから、SiegeがテストするURLのリストを生成し、最後に、テスト結果を調べてパフォーマンスのボトルネックを特定します。
警告: Siegeを使用するのは、自分が所有しているか、テストする権限があるWebサイトのみです。 一部の国では、許可されていないWebサイトに対してSiegeを使用することは犯罪と見なされる場合があります。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- このUbuntu16.04初期サーバーセットアップチュートリアルに従ってセットアップされた1つのUbuntu16.04サーバー。これには、sudo非rootユーザーとファイアウォールが含まれます。 サーバーの初期設定チュートリアルのステップ7で、コマンド
sudo ufw allow 8080
を使用してポート8080
を必ず開いてください。 これは、Sproxyがデフォルトでリッスンするポートです。 - Firefoxがインストールされています。 ローカルコンピュータでmacOSまたはWindowsを使用している場合は、Mozillaの公式Webサイトからインストールファイルをダウンロードする必要があります。 Linuxを使用している場合は、パッケージマネージャーを使用するか、Mozillaの公式手順に従ってFirefoxをインストールする必要があります。 このチュートリアルには、Firefoxバージョン56を操作するための手順が含まれています。
- 公開されているか、Siegeをインストールするサーバーからアクセスできるようにすることができる、所有している、またはテストする権限を持っているWebサイト。
ステップ1—Sproxyの構築とインストール
Sproxyは、事前にパッケージ化されたバイナリとしては利用できないため、公式Webサイトからダウンロードして、ソースからビルドする必要があります。
Sproxyのビルドプロセスは、デフォルトではUbuntuにインストールされていないツールに依存しているため、いくつかの追加パッケージをインストールする必要があります。
まず、パッケージリストを更新して、追加の各パッケージの最新バージョンを取得していることを確認します。
- sudo apt-get update
次に、パッケージをインストールします。
- sudo apt-get install build-essential libnet-ssleay-perl liburi-perl libwww-perl
build-essential
は、DebianベースのLinuxディストリビューションでソフトウェアをビルドするために必要な一般的なライブラリとツールを提供します。libnet-ssleay-perl
、liburi-perl
、およびlibwww-perl
は Perlプログラミング言語は、SSLを介した接続、URI文字列の操作、およびWorldWideWebとのインターフェースをSproxyが依存しています。
次に、ホームディレクトリに移動し、公式WebサイトからSproxyソースコードアーカイブをダウンロードします。
- cd ~
- curl -O http://download.joedog.org/sproxy/sproxy-latest.tar.gz
次に、sproxy
という名前のディレクトリを作成して、Sproxyを組み込み、ソースコードアーカイブを新しいディレクトリに解凍します。
- mkdir sproxy
- tar -zxf sproxy-latest.tar.gz --strip-components=1 --directory="sproxy"
ここで、-zxf
オプションは、tarにgunzip
を指示し、sproxy-latest.tar.gz
ファイルの内容を抽出します。 --strip-components=1
オプションは、各ファイル名から最初の先頭のコンポーネントを削除します。 これにより、アーカイブがsproxy-1.02/sproxy/
ではなく、sproxy
ディレクトリ(--directory
オプションで指定)に解凍されます。
次に、sproxy
ディレクトリに移動して、configure
およびmake
コマンドを使用してSproxyをビルドおよびインストールします。
- cd sproxy
- ./configure
- make
- sudo make install
./configure
コマンドは、必要なすべてのプログラム依存関係とビルドツールがシステムに存在することを確認します。 次に、make
コマンドは、プログラムバイナリをビルドします。 最後に、make install
コマンドは、新しいバイナリをサーバー上の正しい場所にコピーします。 Sproxyは/usr/local/lib/sproxy/JoeDog
に新しいディレクトリを作成するため、root権限でmake install
を実行する必要があります。
最後に、ホームディレクトリに戻って、-v
オプションを使用して冗長モードでSproxyを起動し、Sproxyが正しく機能していることをテストします。
- cd ~
- sproxy -v
出力には、Sproxyがリッスンしているポート、Sproxyが出力を書き込んでいるファイルの場所、およびSproxyがリモートホストからの応答を待機する秒数が示されます。
Sproxy OutputSPROXY v1.02 listening on port 9001
...appending HTTP requests to: /user/urls.txt
...default connection timeout: 120 seconds
Sproxyの起動に失敗した場合は、端末のメッセージを確認して、何が問題だったかを確認してください。
すべてが機能していることを確認したら、CTRL+C
でSproxyを停止します。
これでSproxyを使用する準備ができたので、SiegeでベンチマークするURLのリストを作成するために、Sproxyを介してインターネットに接続するようにFirefoxを変更しましょう。
ステップ2—Sproxyを使用するようにFirefoxを設定する
ここで、Firefoxのネットワーク構成を変更して、Sproxyを介してすべてのWebリクエストを送信し、Siegeに必要なベンチマークターゲットのリストを生成します。
アクセスしたすべてのURLをSproxyに記録させたいので、FirefoxのローカルWebキャッシュもクリアします。 Webキャッシュは、FirefoxがすでにアクセスしたWebサイトからの画像やその他の静的コンテンツのローカルストアです。 デフォルトでは、FirefoxはすでにキャッシュされているWebサイトアセットを再要求しません。
ネットワーク設定の変更
まず、Firefoxの環境設定画面の一般タブでネットワークプロキシの設定を変更します。
- Firefoxを開きます。 (このチュートリアルには、Firefoxバージョン56の手順が含まれています。 その他のバージョンについては、 Firefoxの公式サポートドキュメントを参照してください。)
- 画面右上のハンバーガーメニューをクリックし、環境設定を選択して一般画面に移動します。
- ページの一番下までスクロールして、ネットワークプロキシセクションを見つけます。
- 設定…ボタンをクリックして、接続設定パネルを開きます。
このパネルで、ステップ1でインストールしたSproxyサーバーを介してすべてのリクエストを渡すようにFirefoxを設定します。
- 手動プロキシ設定を選択します。
- HTTPプロキシフィールドにSproxyサーバーのパブリックIPアドレスを入力します。
- Portフィールドでポート番号を
8080
に設定します。 - OKをクリックして変更を保存します。
これで、Sproxy HTTPプロキシサーバーを使用するようにFirefoxが構成されたので、ローカルキャッシュをクリアする準備が整いました。
ローカルキャッシュのクリア
Firefoxは、ローカルキャッシュをオフラインWebコンテンツと呼びます。 これは、Firefoxの環境設定画面のプライバシーとセキュリティセクションにあります。
- 画面右上のハンバーガーメニューをクリックし、環境設定を選択して一般画面に移動します。
- クリックプライバシーとセキュリティ画面の左側にあります。
- ページの一番下までスクロールして、オフラインWebコンテンツとユーザーデータセクションを見つけ、今すぐクリアボタンを押します。
Webキャッシュが空になっているため、Firefoxが検出するすべてのHTTPベースのWebサイトアセットのアドレスは、そのアセットが再キャッシュされるまでSproxyに渡されます。
構成のテスト
FirefoxはすべてのHTTPベースのリクエストをSproxy経由でルーティングするように構成されていますが、ステップ1の最後にCTRL+C
でSproxyを停止しました。 そのため、FirefoxとのHTTP接続を介してWebサイトにアクセスしようとすると、エラーページが表示されます。
このエラーメッセージが表示されない場合は、Firefoxの設定が前のスクリーンショットと一致していることを確認し、HTTPS経由でWebサイトに接続していないことを再確認してください。
Firefoxを再び正常に使用する場合は、ネットワーク設定の変更の前の手順をたどりますが、今回は接続設定でプロキシなしオプションを選択しますパネル。
Sproxy経由でインターネットに接続するようにFirefoxを設定したので、Sproxyを起動し、FirefoxでターゲットWebサイトを閲覧することでURLのリストを作成できます。
ステップ3—Sproxyを起動してURLリストを生成する
このステップでは、Sproxyサーバーを起動し、Firefoxを使用してターゲットWebサイトを閲覧します。 Sproxyは、Firefoxが要求するすべてのHTTPベースのURLを、後でSiegeで使用するファイルに記録します。
まず、ホームディレクトリに移動してSproxyを起動します。
- cd ~
- sproxy -v -t 180 -p 8080 -o mixed-urls.txt your_server_ip
-v
は、端末に要求されているURLを出力します。-t
は、Sproxyがリモートホストからの応答を待機する秒数です。-p
は、Sproxyがリッスンするポートです。-o
は、SproxyがURLを書き込むファイルです。your_server_ip
は、SproxyがバインドするIPアドレスです。
出力には、実行しているSproxyのバージョン、Sproxyがリッスンしているポート、SproxyがURLを書き込んでいるファイル、およびSproxyがリモートホストの応答を待機する時間がすぐに示されます。 テストWebサイトの閲覧を開始すると、出力にはSproxyが記録しているWebページのURLも含まれます。
Sproxy OutputSPROXY v1.02 listening on port 8080
...appending HTTP requests to: mixed-urls.txt
...default connection timeout: 180 seconds
http://www.example.com/
http://www.example.com/index.html
http://www.example.com/about.html
注: Sproxy はHTTPS接続をサポートしていないため、URLのリストを生成するには、HTTPを介してテストサイトを参照する必要があります。 ただし、SiegeはHTTPSをサポートしているため、ステップ5 では、HTTPとHTTPSの両方でWebサイトをテストするためにHTTPのみのURLリストを変更する方法について説明します。
Sproxyを起動したら、Firefoxに戻り、ターゲットサイトの閲覧を開始します。 Sproxyは、Firefoxが要求するすべてのURLをmixed-urls.txt
ファイルに書き込み、同時にURLを端末に出力します。
テストする予定のすべてのWebページにアクセスしたら、CTRL+C
でSproxyを停止します。
これで、FirefoxがテストWebサイトで検出したすべてのHTTPベースのURLのmixed-urls.txt
ファイルにリストが作成されました。 次のステップは、Webサイトに解決されないURLを削除して、許可されたドメインに対してのみSiegeを使用するようにすることです。
ステップ4—URLファイルのサニタイズ
最近のWebサイトは、多くの場合、複数の場所でコンテンツをホストしています。 このコンテンツは、コンテンツ配信ネットワーク(CDN)でホストされている画像、またはGoogleなどのサードパーティサービスでホストされているフォントである可能性があります。 Siegeを実行するときは、テストする権限があるドメインのみをベンチマークしていることを確認する必要があります。 したがって、mixed-urls.txt
ファイル内のターゲットWebサイトを指していないURLを削除する必要があります。
ユーザー指定の正規表現に対してプレーンテキスト入力を検索するユーティリティであるgrepを使用して、テストドメインに一致するURLのみを検索し、結果をにリダイレクトします。 urls.txt
という名前の新しいファイル。
- grep -a "^http://www.example.com" mixed-urls.txt > urls.txt
-a
フラグは、バイナリファイルをテキストファイルのように扱うようにgrepに指示します。 これが必要なのは、ブラウザがバイナリデータを含むPOSTリクエストを作成し、Sproxyがそのデータをmixed-urls.txt
に書き込む場合があるためです。 mixed-urls.txt
にバイナリデータがある場合、-a
フラグがないとgrepは失敗します。
正規表現の用語では、^
文字は、文字列が一致と見なされるにはhttp://www.example.com
で始まる必要があることを示します。
このコマンドはターミナルに出力を生成しませんが、urls.txt
という名前の新しいファイルを作成します。
次に、urls.txt
を開いて、すべての行がテストWebサイトのドメイン名で始まることを確認し、そうでない行を削除します。
- nano urls.txt
変更を保存し、編集が完了したらファイルを閉じます。
これで、URLリストにテストする権限があるURLのみが含まれるようになったため、Siegeをインストールする準備が整いました。 HTTPS経由でWebサイトのベンチマークも行う場合は、ステップ5 のオプションの手順に従って、URLのHTTPSバージョンを含む2番目のURLファイルを作成します。
手順5— HTTPS URLファイルの作成(オプション)
多くのWebサイトは、HTTPとHTTPSの両方、またはHTTPSのみを介して実行されるため、HTTPSを介してWebサイトのベンチマークを実行できることも重要です。 これはSiegeができることです。 https
で始まるURLのリストを指定するだけで済みます。
まず、cat
コマンドを使用してurls.txt
を開き、その内容をテキストの解析と変換のためのユーティリティであるsedに渡します。 sedは、http
のすべてのインスタンスをhttps
に置き換え、結果をターミナルに表示します。
- cat urls.txt | sed 's|http|https|'
出力される各URLがhttps
で始まることを除いて、出力はurls.txt
ファイルに既にあるURLのリストと同じになります。
Example Outputhttps://www.example.com/
https://www.example.com/index.html
https://www.example.com/about.html
出力を確認したら、コマンドを再実行します。今回は、urls-https.txt
という名前の新しいファイルに出力を書き込みます。
- cat urls.txt | sed 's|http|https|' > urls-https.txt
このコマンドはすべてurls-https.txt
にリダイレクトされているため、端末への出力は生成されません。
更新されたURLリストができたので、Siegeをインストールしてテストを開始する準備が整いました。
ステップ6—Siegeによるベンチマークとテスト
Webサイトのテストを開始する前に、まずSiegeをインストールする必要があります。
Siegeは標準のUbuntuパッケージリポジトリから入手できるため、apt-get
を使用してインストールします。
- sudo apt-get install siege
Siegeには、インターネットとベンチマークの2つの操作モードがあります。 インターネットモードは、ターゲットWebサイトを閲覧する訪問者をシミュレートしますが、ベンチマークモードは、Webサーバーが処理できる限り迅速に要求を行います。 まず、Siegeをインターネットモードで実行します。
インターネットモードは、時間の経過とともに同時訪問者の数を増やすことにより、サーバーの負荷をゆっくりと増やすのに適しています。 このモードでは、長期間にわたって負荷が持続する可能性もあります。これは、バックアップの作成などの操作中にWebサイトのパフォーマンスがどうなるかを調べる必要がある場合に役立ちます。
ホームディレクトリに移動し、インターネットモードでSiegeを起動します。 HTTPのみのアドレスに対してテストする場合は、urls_file
をurls.txt
に置き換えてください。 ステップ5に従い、HTTPSアドレスに対してテストする場合は、urls_file
をurls-https.txt
に置き換えます。
- cd ~
- siege --internet --concurrent=5 --time=30S --log="siege-internet.log" --file="urls_file"
--internet
は、Siegeをインターネットモードに設定します。--concurrent
は、シミュレートする訪問者の数です。 この例では、サーバーを圧倒することなくトラフィックを生成するために5人の同時ユーザーをシミュレートするようにSiegeに指示しました。 サーバーの機能に慣れてきたら、必要に応じてこの数を増やすことができます。--time
は、Siegeの実行時間です。 この値は、S
で秒、M
で分、H
で時間に設定できます。 この例では、サーバーを圧倒することなくトラフィックを生成するために、Siegeに30秒間実行するように指示しました。 将来的には、さまざまな時間の長さを試して、サーバーがトラフィックの持続的な負荷にどのように応答するかを確認できます。--log
は、Siegeにテスト結果を書き込む場所へのパスです。 デフォルトでは、この場所は/var/log/siege.log
であり、sudo権限が必要です。--file
は、Siegeがテストに使用するURLを含むファイルへのパスです。
Siegeを最初に起動すると、使用しているバージョン番号とシミュレートしている同時ユーザーの数が報告されます。 次に、テストが開始されたことを通知します。
Siege Output at Start of Run** SIEGE 3.0.8
** Preparing 5 concurrent users for battle.
The server is now under siege...
Siegeが実行を完了するか、CTRL+C
で終了すると、テストの結果と結果ログファイルの場所も表示されます。
Siege Output at End of Run...
Lifting the server siege... done.
Transactions: 157 hits
Availability: 100.00 %
Elapsed time: 29.72 secs
Data transferred: 0.15 MB
Response time: 0.49 secs
Transaction rate: 5.28 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 2.59
Successful transactions: 161
Failed transactions: 0
Longest transaction: 0.74
Shortest transaction: 0.27
FILE: siege-internet.log
You can disable this annoying message by editing
the .siegerc file in your home directory; change
the directive 'show-logfile' to false.
出力に含まれる統計は複雑であるため、ステップ7で詳細に調査します。
それでは、Siegeをベンチマークモードで実行して、サイトが一度に処理できるページリクエストの最大数を見つけましょう。 これは、どの追加テクノロジーがWebサイトのパフォーマンスを向上させる可能性があるかを判断する際に役立つ情報です。 さらに、ステップ8 でこのモードを詳しく調べるとわかるように、ベンチマークモードはリソースのボトルネックを浮き彫りにすることができます。
--internet
の代わりに--benchmark
を使用して、今回はベンチマークモードでSiegeを再起動します。
- siege --benchmark --time=30S --log="siege-benchmark.log" --file="urls_file"
出力は以前と同じ形式に従いますが、今回はモードが異なるため結果が異なります。
Siege Output** SIEGE 3.0.8
** Preparing 5 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done.
Transactions: 444 hits
Availability: 100.00 %
Elapsed time: 29.72 secs
Data transferred: 18.16 MB
Response time: 0.49 secs
Transaction rate: 105.28 trans/sec
Throughput: 4.41 MB/sec
Concurrency: 14.14
Successful transactions: 421
Failed transactions: 0
Longest transaction: 0.74
Shortest transaction: 0.27
FILE: siege-benchmark.log
You can disable this annoying message by editing
the .siegerc file in your home directory; change
the directive 'show-logfile' to false.
インターネットモードからの統計と同様に、ベンチマークモードからの統計は複雑です。 これらについては、ステップ7および8で詳しく説明します。
Siegeを使用してサイトのテストとベンチマークを行ったので、出力をより詳細に調査し、統計を実際に利用できます。
ステップ7—Siegeの結果を理解する
Webサイトのパフォーマンスを理解し、ボトルネックを特定し、アップグレードの取り組みをどこに集中させるかを決定することになると、Siegeは強力な資産になる可能性があります。 それが提供する統計は、あなたのウェブサイトの全体的な健康状態への深い洞察を与えることができる一連の測定基準をカバーしています。
ステップ6で見たように、Siegeの出力は一般的に次のようになります。
Siege Output at End of Run...
Transactions: 904 hits
Availability: 97.41 %
Elapsed time: 4.59 secs
Data transferred: 4.37 MB
Response time: 0.07 secs
Transaction rate: 196.95 trans/sec
Throughput: 0.95 MB/sec
Concurrency: 12.86
Successful transactions: 904
Failed transactions: 24
Longest transaction: 1.95
Shortest transaction: 0.00
...
具体的には、これらのメトリックは次のことを意味します。
Transactions
は、Siegeが行ったリクエストの総数です。Availability
は、 4xxおよび5xxレベルのHTTPエラーコードを含む、Webサーバーが応答した要求の割合です。Elapsed time
は、テストが実行された時間です。Data transferred
は、Siegeがサイトのテストに使用した帯域幅の合計です。Response time
は、Webサーバーが要求に応答するのにかかった平均時間です。Transaction rate
は、Webサーバーが処理した1秒あたりの平均トランザクション数です。Throughput
は、Webサーバーが提供した1秒あたりのデータ量です。Concurrency
は、開いている同時接続の平均数です。Successful transactions
は、HTTPステータスコードが400未満で応答されたトランザクションの総数です。Failed transactions
は、400を超えるHTTPステータスコードで応答されたトランザクションの総数です。Longest transaction
は、最長のリクエストが完了するまでにかかった時間です。Shortest transaction
は、最短のリクエストが完了するまでにかかった時間です。
Transaction rate
およびFailed transactions
は、Webサーバーの全体的な状態の最速のリトマス試験を提供します。
Transaction rate
は、Webサーバーが処理できる1秒あたりのページ数であるため、Webサイトの速度を表します。 この数値が大きいほど、Webサイトが処理できる訪問者が多くなり、訪問者が各ページをより速く受け取ることができます。 Siegeを使用してWebサイトの一般的な応答性を向上させている場合、これは増やしたい数です。
Failed transactions
値は、503 Service Unavailable
などのエラーコードを含むWebサーバーからの応答を指します。 これらのエラーは、多くの場合、受信している要求の数を処理できないデータベースや、RAMを使い果たしたWebサーバーなどの問題を示しています。 この数がゼロ以外の場合は、Webサーバーのログファイルを調べて、発生したエラーを正確に確認し、問題を解決する方法について指示を得る必要があります。
Transaction rate
を増やし、Failed transactions
を減らすために変更を加えるときは、Siegeを実行するたびに作成するログファイルも参照してください。これには、表示されるのと同じ統計がすべて含まれています。ターミナルとテストの日時。 これは、あなたの努力の全体的な軌道を追跡するのに役立ちます。
Siegeの出力を調べて、Webサーバーの速度と堅牢性を判断したので、次に、この同じ情報を使用してパフォーマンスのボトルネックを特定して取り除く方法を確認します。
ステップ8—パフォーマンスのボトルネックを特定する
ベンチマークモードでは、SiegeはWebサーバーが処理できる数のリクエストを1秒あたりに作成します。 サーバーが提供できるページの最大数に達すると、サーバーはリソース制限に達しました。
影響を受ける可能性が最も高い4つのリソースは次のとおりです。
- 羊
- CPU
- ディスク
- ネットワーク帯域幅
ベンチマークモードを最大限に活用するには、Siegeと同時にいくつかの追加ツールを実行する必要があります。これにより、Siegeがテスト負荷を増やしたときにシステム全体で何が起こるかを監視できます。
システムリソースの動的なリアルタイムビューを提供するツールであるtopを使用して、最初の3つのリソース(RAM、CPU、およびディスクの使用量)を監視できます。
Ubuntuにはデフォルトでtopが付属しているため、インストールする必要はありません。 コマンドtop
を実行するだけです。
上部に表示される情報は、2つのセクションに分かれています。
Sample top Outputtop - 21:02:32 up 50 min, 1 user, load average: 0.07, 0.02, 0.00
Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie
%Cpu(s): 37.3 us, 7.3 sy, 0.0 ni, 99.3 id, 8.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1015200 total, 63536 free, 431456 used, 520208 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 512308 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3249 www-data 20 0 469592 92276 33488 D 24.6 9.1 0:05.01 apache2
3239 www-data 20 0 442836 75080 41896 S 5.6 7.4 1:31.97 apache2
3572 www-data 20 0 424372 35272 21164 S 4.0 3.5 0:02.69 apache2
出力の最初の5行で構成される上部のセクションには、現在のシステム使用状況の要約が表示されます。
下のセクションには、システムで現在実行されている個々のサーバープロセスのリストが、各プロセスの識別番号、所有者、優先度、適切な値、仮想メモリの使用、物理メモリの使用、共有メモリの使用、ステータス、CPU使用の割合とともに表示されます。メモリ使用量の割合、アクティビティの合計時間、および名前。
topは、プロセスの管理および CPU使用の監視に役立つツールですが、この場合、Siegeベンチマークテストの強要の下で、システムについて何がわかるかを確認したいと思います。 。
CPU使用率は、%Cpu(s): 37.3 us, 7.3 sy,
と表示されます。 これらの値は、ユーザープロセスがCPUの37.3%を消費し、システムプロセスが7.3%を消費していることを示しています。 これらの2つの値を合計すると、合計CPU使用率が得られます。
サーバーが100%またはほぼ100%のCPU使用率で実行されている場合は、プロセスのリストの上位のエントリをチェックして、1つ以上が異常に大量のCPUを消費していないかどうかを確認します。 その場合は、CPUの使用量を減らすために、プロセスを再構成または微調整することを検討してください。 それが不可能な場合は、サーバーのCPUをアップグレードする必要があります。
それでは、メモリ使用量を調べてみましょう。
Sample top Outputtop - 21:02:32 up 51 min, 1 user, load average: 0.21, 0.47, 0.80
Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie
%Cpu(s): 17.4 us, 3.4 sy, 0.0 ni, 79.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 991.406 total, 223.914 free, 395.621 used, 371.871 buff/cache
MiB Swap: 0.000 total, 0.000 free, 0.000 used. 526.156 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3249 www-data 20 0 469592 92276 33488 D 24.6 9.1 0:05.01 apache2
3239 www-data 20 0 442836 75080 41896 S 5.6 7.4 1:31.97 apache2
3572 www-data 20 0 424372 35272 21164 S 4.0 3.5 0:02.69 apache2
デフォルトでは、RAM使用量は4行目にキロバイト単位で表示されます。 前の出力例では、すでにSHIFT+E
を1回押しており、数値をメガバイトに変換して数値を操作しやすくしています。 SHIFT+E
をもう一度押して値をギガバイトに変換し、SHIFT+E
を押し続けるとデフォルトのキロバイト表示に戻ります。
total
の値は、サーバーで使用可能なメモリの合計量です。 カーネルは起動時にいくらかのメモリを予約するので、1024MBのマシンはここに991MBのメモリを表示することに注意してください。
avail Mem
は、システムに残っているメモリの量を示します。 この数は、RAMの使用量が増えるにつれて小さくなり、サーバーにメモリが残っていない場合は最終的にゼロになります。
CPU使用率と同様に、avail Mem
がゼロまたはその近くで実行されている場合は、プロセスのリストで、異常に大量のメモリを消費するエントリを探します。 可能であれば、これらのプロセスを再構成または微調整して、使用するメモリを減らすか、サーバーのRAMの量をアップグレードしてください。
最後に、ディスク使用量を見てみましょう。
Sample top Outputtop - 21:02:32 up 52 min, 1 user, load average: 0.21, 0.47, 0.80
Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie
%Cpu(s): 17.4 us, 3.4 sy, 0.0 ni, 79.2 id, 31.6 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1015200 total, 63536 free, 431456 used, 520208 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 512308 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3249 www-data 20 0 469592 92276 33488 D 24.6 9.1 0:05.01 apache2
3239 www-data 20 0 442836 75080 41896 S 5.6 7.4 1:31.97 apache2
3572 www-data 20 0 424372 35272 21164 S 4.0 3.5 0:02.69 apache2
関心のあるディスク使用量、I / O待機は、使用可能なディスクスペースの量ではなく、サーバーへのディスクアクセスの速度が低下している量です。 特に回転するプラッタハードディスクを使用するサーバーでのディスクアクセスは非常に遅く、サーバーがディスクにアクセスするたびに、CPUは情報が取得されるのを待つ必要があります。
Topは、この情報をwa
値として報告します。 これは、CPUがディスクからのデータを待機してアイドル状態になっている時間の割合を示します。 この数値は、可能な限り0.0に近づける必要があります。
前の例では、wa
の値は31.6
です。 これは、CPUがディスクからのデータを待機する時間の3分の1を費やしていることを意味します。 これは非常に長い時間であり、Webサイトのパフォーマンスに深刻な影響を及ぼします。
I / O待機は、多くの場合、ファイルを求めてディスクにアクセスしたり、ローカルデータベースを繰り返し呼び出したりした結果です。 wa
が0.0をはるかに超える場合は、静的リソースをコンテンツ配信ネットワーク(CDN)などのリモートの場所に移動するか、アプリケーションが関連するローカルデータベースに移動する回数を減らす方法を検討してください。
Q
を押してトップを終了します。
ここで取り上げる最後のリソースは、ネットワークの使用状況です。 これを監視するには、Bandwidth MonitorNewGenerationツールを使用します。
このツールをapt-get
でインストールし、コマンドbwm-ng
で実行します。
- sudo apt-get install bwm-ng
- bwm-ng
出力の上部には、帯域幅モニターの新世代のバージョン番号、データが更新される頻度(デフォルトでは0.5秒ごと)、使用可能なネットワークインターフェイスを決定するために使用される入力ソース(デフォルトでは/proc/net/dev
Linux)、および表示されている統計(デフォルトではデータ使用量rate
)。
出力の下部には、ネットワークインターフェイスごとの受信データ(Rx
)、送信データ(Tx
)、および合計データ(Total
)の量を報告するテーブルが含まれています。 。
最後の行には、すべてのネットワークインターフェイスの合計値が表示されます。
Sample bwm-ng Output bwm-ng v0.6.1 (probing every 0.500s), press 'h' for help
input: /proc/net/dev type: rate
- iface Rx Tx Total
==============================================================================
lo: 0.00 KB/s 0.00 KB/s 0.00 KB/s
eth0: 30.99 KB/s 499.11 KB/s 530.11 KB/s
------------------------------------------------------------------------------
total: 30.99 KB/s 499.11 KB/s 530.11 KB/s
ネットワーク帯域幅が問題を引き起こす場合、通常はTx
が最大になっていることが原因です。 この問題を解決するには、ホスティングプロバイダーからサーバーの接続速度を取得し、bwm-ng
で示される速度と比較します。 bwm-ng
で示される速度が常にサーバーで利用可能な最大帯域幅であるか、それに近い場合は、ホスティングプランをアップグレードするか、別のプロバイダーに完全に移行することを検討する必要があります。
テストが終了したら、CTRL+C
を押してBandwidthMonitorNewGenerationを終了します。
結論
このガイドでは、SiegeベンチマークツールとSproxyプロキシサーバーを使用して、Webサーバーに構成可能な負荷を生成し、それを最大スループットにプッシュしました。 これらのツールは、パフォーマンスの問題を特定し、十分な情報に基づいたアップグレードを計画するのに役立つため、Webサイトの展開に非常に役立ちます。
ディスクI/Oとメモリのボトルネックを減らす別の方法については、 Varnish HTTPCacheを参照してください。 Varnishは、静的なWebサイト資産を格納する使いやすいリバースプロキシであり、RAM使用量とディスクI/Oの両方を削減します。
WebサイトでPHPを使用している場合は、標準のPHP実装の代わりにPHP-FPMをインストールすることを検討してください。 PHP-FPMは、PHPベースのWebページを提供するためのCPU要件を削減し、それによってWebサイト全体を高速化します。