前書き
Siegeは、Webページを要求することによってWebサーバーをテストするWebサイト用の構成可能なベンチマークおよびテストツールです。 Siegeが要求する1秒あたりのページ数は、1秒あたり数ページからWebサイトが処理できる最大数までの任意の値に設定できます。
この情報は、どのサーバーリソースが最初に使い果たされ、どのトラフィックレベルであるかを強調することにより、パフォーマンスのボトルネックを発見するのに非常に役立ちます。 この情報を使用して、ライブサイトに障害が発生する前に、サーバーの構成を変更したり、サーバーのハードウェアをアップグレードしたりできます。 さらに、バックアップなどの一般的なシステム管理手順をシミュレートした負荷の下でテストして、Webサイトのパフォーマンスへの影響を判断できます。
このガイドでは、Siegeをインストールして構成し、ベンチマークモードとブラウジングモードで実行します。 ベンチマークモードは、Webサーバーが処理できる数のリクエストを行い、ブラウジングモードは、Webサイトへの構成可能な数の訪問者をシミュレートします。
Firefoxを使用すると、プロキシサーバーを介して実行されるインターネット接続の構成が特に簡単になるため、これを使用して、Sproxyプロキシサーバーを介してインターネットに接続します。 Sproxyは、Siegeと連動するように特別に作成されたものであり、Sproxyを通過してファイルに送信されるすべてのリクエストのURLを記録します。 このファイルを使用して、テストするURLをSiegeに伝えます。
このチュートリアルの最初の部分では、Sproxyをインストールし、Firefoxを介してインターネットに接続するようにFirefoxを構成します。 そこから、SiegeをテストするURLのリストを生成し、最後にテスト結果を調べてパフォーマンスのボトルネックを特定します。
[.warning]#Warning: Siegeは、所有しているか、テストする権限があるWebサイトのみをテストします。 一部の国では、許可されていないWebサイトに対してSiegeを使用すると、犯罪と見なされる場合があります。
#
前提条件
このチュートリアルを完了するには、次のものが必要です。
-
sudo非rootユーザーとファイアウォールを含むthis Ubuntu 16.04 initial server setup tutorialをフォローしてセットアップされた1つのUbuntu16.04サーバー。 コマンド
sudo ufw allow 8080
を使用して、サーバーの初期セットアップチュートリアルのStep 7でポート8080
を必ず開いてください。 これは、Sproxyがデフォルトでリッスンするポートです。 -
Firefoxがインストールされました。 ローカルコンピュータでmacOSまたはWindowsを使用している場合は、official Mozilla websiteからインストールファイルをダウンロードする必要があります。 Linuxを使用している場合は、パッケージマネージャーを使用するか、Mozilla’s official instructionsに従ってFirefoxをインストールする必要があります。 このチュートリアルには、Firefoxバージョン56を使用するための手順が含まれています。
-
所有している、またはテストする許可を持っているWebサイトは、公開されているか、Siegeをインストールするサーバーからアクセス可能にすることができます。
ステップ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 programming languageのライブラリです。 ■SproxyがSSLを介した接続の確立、URI文字列の操作、およびWorld WideWebとのインターフェースに依存している。
次に、ホームディレクトリに移動し、公式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のネットワーク設定を変更して、すべてのWebリクエストをSproxy経由で送信し、Siegeに必要なベンチマークターゲットのリストを生成します。
SproxyはアクセスするすべてのURLを記録するため、FirefoxのローカルWebキャッシュもクリアします。 Webキャッシュは、FirefoxがすでにアクセスしたWebサイトの画像やその他の静的コンテンツのローカルストアです。 デフォルトでは、Firefoxは既にキャッシュされているWebサイト資産を再要求しません。
ネットワーク設定の変更
まず、FirefoxのメインPreferences画面のGeneralタブでNetwork Proxy設定を変更します。
-
Firefoxを開きます。 (このチュートリアルには、Firefox version 56の説明が含まれています。 他のバージョンについては、Firefox’s official support documentationを参照してください。)
-
画面の右上隅にあるハンバーガーメニューをクリックし、Preferencesを選択してGeneral画面に移動します。
-
ページの一番下までスクロールして、Network Proxyセクションを見つけます。
-
Settings…ボタンをクリックして、Connection Settingsパネルを開きます。
このパネルで、Step 1にインストールしたSproxyサーバーを介してすべての要求を渡すようにFirefoxを構成します。
-
Manual proxy configurationを選択します。
-
SproxyサーバーのパブリックIPアドレスをHTTP Proxyフィールドに入力します。
-
Portフィールドでポート番号を
8080
に設定します。 -
OKをクリックして変更を保存します。
これでFirefoxがSproxy HTTP Proxyサーバーを使用するように設定されたので、ローカルキャッシュをクリアする準備ができました。
ローカルキャッシュのクリア
FirefoxはローカルキャッシュをOffline web contentと呼びます。 これは、FirefoxのPreferences画面のPrivacy and Securityセクションにあります。
-
画面の右上隅にあるハンバーガーメニューをクリックし、Preferencesを選択してGeneral画面に移動します。
-
画面の左側にあるPrivacy & Securityをクリックします。
-
ページの一番下までスクロールしてOffline Web Content and User Dataセクションを見つけ、Clear Nowボタンを押します。
Webキャッシュが空になったため、Firefoxが検出したすべてのHTTPベースのWebサイト資産のアドレスは、その資産が再キャッシュされるまでSproxyに渡されます。
構成のテスト
FirefoxはすべてのHTTPベースのリクエストをSproxy経由でルーティングするように構成されていますが、Step 1の最後にCTRL+C
を付けてSproxyを停止しました。 そのため、現在FirefoxでHTTP接続を介してWebサイトにアクセスしようとすると、エラーページが表示されます。
このエラーメッセージが表示されない場合は、Firefoxの設定が前のスクリーンショットと一致していることを確認し、HTTPS経由でWebサイトに接続していないことを再確認してください。
Firefoxを再び正常に使用する場合は、Modifying the Network Settingsの前の手順を再度トレースしますが、今回は、Connection SettingsパネルでNo proxyオプションを選択します。
Sproxyを介してインターネットに接続するようにFirefoxを構成したので、Sproxyを起動し、FirefoxでターゲットWebサイトを参照することにより、URLのリストを作成できます。
手順3 — Sproxyの起動とURLリストの生成
この手順では、Sproxyサーバーを起動し、Firefoxを使用してターゲットWebサイトを閲覧します。 Sproxyは、Firefoxが後でSiegeで使用するファイルに要求するすべてのHTTPベースのURLを記録します。
まず、ホームディレクトリに移動して、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
[.note]#Note: URLのリストを生成するためのSproxydoes not support HTTPS connections, so you must browse your test site via HTTP。 ただし、SiegeはHTTPSをサポートしており、Step 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を実行するときは、テストする権限があるドメインのみをベンチマークするようにします。 したがって、ターゲットWebサイトを指していないmixed-urls.txt
ファイル内のURLを削除する必要があります。
ユーザー指定のregular expressionsに対してプレーンテキスト入力を検索するユーティリティであるgrepを使用して、テストドメインとredirect the resultsをurls.txt
という名前の新しいファイルに一致するURLのみを検索します。 。
grep -a "^http://www.example.com" mixed-urls.txt > urls.txt
-a
フラグは、バイナリファイルをテキストファイルのように扱うようにgrepに指示します。 これが必要なのは、ブラウザがバイナリデータを含むPOSTリクエストを作成し、Sproxyがそれをmixed-urls.txt
に書き込むためです。 mixed-urls.txt
にバイナリデータがある場合、grepは-a
フラグなしで失敗します。
正規表現の用語では、^
文字は、文字列が一致と見なされるにはhttp://www.example.com
で始まる必要があることを示します。
このコマンドはターミナルに出力を生成しませんが、urls.txt
という名前の新しいファイルを作成します。
次に、urls.txt
を開いて、すべての行がテストWebサイトのドメイン名で始まることを確認し、そうでない行を削除します。
nano urls.txt
編集が完了したら、変更を保存してファイルを閉じます。
URLリストには、テストする権限があるURLのみが含まれるようになったため、Siegeをインストールする準備が整いました。 HTTPS経由でWebサイトのベンチマークも行う場合は、Step 5のオプションの手順に従って、HTTPSバージョンのURLを含む2番目のURLファイルを作成します。
手順5 — HTTPS URLファイルの作成(オプション)
多くのWebサイトは、HTTPとHTTPSの両方、またはHTTPSのみで実行されているため、WebサイトもHTTPSでベンチマークできることが重要です。 これは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をインターネットモードで実行します。
インターネットモードは、時間の経過とともに同時訪問者の数を増やすことにより、サーバーの負荷を徐々に増やすのに適しています。 また、このモードでは、長時間にわたる持続的な負荷を作成できます。これは、バックアップの作成などの操作中にウェブサイトのパフォーマンスに何が起こるかを調べる必要がある場合に便利です。
ホームディレクトリに移動し、Siegeをインターネットモードで起動します。 HTTPのみのアドレスに対してテストする場合は、urls_file
をurls.txt
に置き換えます。 Step 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.
出力に含まれる統計は複雑であるため、Step 7で詳細に調査します。
次に、Siegeをベンチマークモードで実行して、サイトが一度に処理できるページリクエストの最大数を確認します。 これは、どの追加テクノロジーがウェブサイトのパフォーマンスを改善できるかを判断する際に役立つ情報です。 さらに、ベンチマークモードでは、Step 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.
Siegeを使用してサイトのテストとベンチマークを行ったので、出力をより詳細に調査し、統計を実際に使用できます。
ステップ7 — Siegeの結果を理解する
Webサイトのパフォーマンスを理解し、ボトルネックを特定し、アップグレード作業をどこに集中させるかを決定することになると、Siegeは強力な資産になる可能性があります。 それが提供する統計は、ウェブサイトの全体的な健全性についての深い洞察を与えることができる幅広い指標をカバーしています。
Step 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 and 5xx-level HTTP error codesを含む、Webサーバーが応答した要求の割合です。 -
Elapsed time
は、テストが実行された時間です。 -
Data transferred
は、Siegeがサイトのテストに使用した帯域幅の合計です。 -
Response time
は、Webサーバーが要求に応答するのにかかった平均時間です。 -
Transaction rate
は、Webサーバーが処理した1秒あたりの平均トランザクション数です。 -
Throughput
は、Webサーバーが提供した1秒あたりのデータ量です。 -
Concurrency
は、開いている同時接続の平均数です。 -
Successful transactions
は、400未満のHTTP status codeで応答されたトランザクションの総数です。 -
Failed transactions
は、HTTPステータスコードgreater than 400で応答されたトランザクションの総数です。 -
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サーバーなどの問題を示しています。 この数がゼロ以外の場合は、ウェブサーバーのログファイルを調べて、発生したエラーを正確に確認し、問題の解決方法に関する指示を得る必要があります。
時間の経過とともにTransaction rate
を増やし、Failed transactions
を減らすように変更を加えるときは、Siegeを実行するたびに作成するログファイルも参照してください。ログファイルには、ターミナルとテストの日時。 これは、努力の全体的な軌跡を追跡するのに役立ちます。
Siegeの出力を調べてWebサーバーの速度と堅牢性を判断したので、この同じ情報を使用してパフォーマンスのボトルネックを特定および削除する方法を確認します。
ステップ8 —パフォーマンスのボトルネックを特定する
ベンチマークモードでは、SiegeはWebサーバーが処理できる1秒あたりのリクエスト数を毎秒行います。 サーバーが提供できるページの最大数に達すると、サーバーはresource limitに達します。
影響を受ける可能性が最も高い4つのリソースは次のとおりです。
-
RAM
-
CPU
-
Disk
-
ネットワーク帯域幅
ベンチマークモードを最大限に活用するには、Siegeと同時にテストツールをいくつか実行する必要があります。これにより、Siegeのテスト負荷が増加したときにシステム全体で何が起こるかを監視できます。
システムリソースの動的なリアルタイムビューを提供するツールであるtopを使用すると、RAM、CPU、およびディスク使用量の最初の3つのリソースを監視できます。
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行で構成される上部セクションには、現在のシステム使用状況の概要が表示されます。
下のセクションには、システムで現在実行されている個々のサーバープロセスのリストと、各プロセスの識別番号、所有者、優先度、nice値、仮想メモリ使用、物理メモリ使用、共有メモリ使用、ステータス、CPU使用率、メモリ使用率、アクティビティの合計時間、および名前。
topはmanaging processesとmonitoring CPU useにとって便利なツールですが、この場合、Siegeベンチマークテストの強要の下で、システムについて何がわかるかを確認したいと思います。
CPU使用率は、%Cpu(s): 37.3 us, 7.3 sy,
を読み取ります。 これらの値は、ユーザープロセスがCPUの37.3%を消費し、システムプロセスが7.3%を消費していることを示しています。 これら2つの値を一緒に追加すると、合計CPU使用率が取得されます。
サーバーが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
値は、サーバーで使用可能なメモリの合計量です。 カーネルはブート時にメモリを予約するため、1024 MBのマシンではここに991 MBのメモリが表示されることに注意してください。
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を費やしていることを意味します。 これは長い時間であり、ウェブサイトのパフォーマンスに深刻な影響を及ぼします。
I/O wait is often the result of accessing the disk for files or making repeated calls to local databases. wa
が0.0をはるかに超える場合は、静的リソースをコンテンツ配信ネットワーク(CDN)などのリモートの場所に移動するか、アプリケーションが関連するローカルデータベースに移動する回数を減らす方法を調査してください。
Q
を押してtopを終了します。
最後に確認するリソースは、ネットワークの使用です。 これを監視するには、Bandwidth Monitor New Generationツールを使用します。
このツールをapt-get
でインストールし、コマンドbwm-ng
で実行します。
sudo apt-get install bwm-ng
bwm-ng
出力の上部には、帯域幅モニターの新世代のバージョン番号、データが更新される頻度(デフォルトでは0.5秒ごと)、使用可能なネットワークインターフェイスを決定するために使用される入力ソース(Linuxではデフォルトで/proc/net/dev
)が表示されます。 )、および表示されている統計(デフォルトではデータ使用率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
を押してBandwidth Monitor NewGenerationを終了します。
結論
このガイドでは、SiegeベンチマークツールとSproxyプロキシサーバーを使用して、Webサーバーで構成可能な負荷を生成し、最大スループットにプッシュしました。 これらのツールは、パフォーマンスの問題を特定し、十分な情報に基づいたアップグレードを計画するのに役立つため、Webサイトの展開に非常に役立ちます。
ディスクI / Oとメモリのボトルネックを減らす別の方法については、Varnish HTTP Cacheを参照してください。 Varnishは、静的なWebサイト資産を保存する使いやすいリバースプロキシで、RAM使用量とディスクI / Oの両方を削減します。
WebサイトでPHPを使用している場合は、標準のPHP実装の代わりにPHP-FPMをインストールすることを検討してください。 PHP-FPMは、PHPベースのWebページを提供するためのCPU要件を削減するため、Webサイト全体の速度が向上します。