5.2.2 forkにかかる時間
Apacheのシステムコールにかかった時間から測定結果を調べた．sc usageを用いてシステムコールの時
間を測定をしたところ，forkが終了するまでの時間9.0secに対して使用したCPU TIMEは0.012secとなっ ており，CPUに負荷がかかっていない事がわかった．
また1sec毎のプロセスの数の推移を調べたところ，プロセスが2の乗数ごとに増加している事がわかった．
図22:一秒毎のfork数
この図22はhttperfのパラメータを変化させても同じようになった．
このことからpreforkはプロセスの増加が緩やかなのはCPUに負荷がかかっていたためではなく，prefork の実装によるものではないかと考えられる．一方，どちらの場合も処理の完了には同じ時間がかかってお り，この点については引き続き調査が必要である．
本研究ではサーバの最大パフォーマンスを調べる事を目指すため，StartServers,MaxSpareServersははじ
めからMaxclientsと同値にしてパフォーマンス測定を行う．
5.3 Connection time の調査
この節ではコネクションの性能調査を行う．調査にはagile環境を用いた．
コネクションの性能調査においてはhttperfの出力にあるConnection Sectionを参考にする．Connection SectionではTCPコネクションの結果について出力される．今回その出力のConnection timeについ て着目する．Connection timeはTCPコネクションが完了するのにかかった時間の平均をとったもの で，他の環境においても比較が容易であり一つの性能の指標となる．
性能調査をする際は，どこが性能のボトルネックになるかを考えなければならない．Webサーバの性能 調査する際にクライアント側の方が性能を出し切れていない場合は，Webサーバの性能を最大限に出し切
5.3 Connection timeの調査
れていない事になる．そのためWebサーバの性能を見るためにはWebサーバが性能のボトルネックとなっ ている必要がある．また，ボトルネックとして見るものにはCPU使用率，データ通信量などがあげられる．
WebサーバのCPU使用率及びクライアントのCPU使用率を確認するためにまず，デフォルト状態でhttperf を行い，そのCPU使用率を確認する．クライアントのパラメータは--wsess=5000,2,1 --rate5000 で，Webサーバのプロセス数は5000での結果を示す．
図23:デフォルトでのクライアントのCPU使用率 図24:デフォルトでのWebサーバのCPU使用率
この図23，図24を見ると明らかにWebサーバ側のCPU使用率に余裕がある事がわかる．ここからクラ イアント側のCPU使用率を減らし，Webサーバ側のCPU使用率を高くする事を目指す．
5.3.1 FD SETSIZE変更
httperfの性能を向上させるためにhttperfのFD SETSIZEを低く設定する．httperfは処理にselect()を用 いているためこの値を低くする事で，select()による負荷を減らす事ができるかを試した．しかしこれは変 化がほとんど見られなかったため，更に別の方法も合わせて試す．
5.3.2 httperfを複数クライアントで実行
httperfをクライアント側で複数同時実行することを試す．まず，一つのマシンでhttperfを同時実行する
ためには，スクリプトを用いる方法が考えられる．複数のクライアントをバックグラウンドで実行させる ことで同時実行を試した．しかしこの手法を試したところ，コマンド実行のタイミングに誤差が生じてし まった．
そのため本実験では別の手法としてコマンドの複数実行にcrontabを用いた．crontabは設定しておいた時 刻にコマンドを実行する事ができるものである．同じ時刻に同じコマンドを設定しておく事で同時実行が実 現できるか試したところ，きちんと処理が行われていたため同時実行の際にはこの手法を用いる．crontab を用いた手法は7.3節で詳しく説明する．
しかしそのCPU使用率を確認したところまだWebサーバ側に余裕があったため，更に別の方法も合わせ て試す．
5.3 Connection timeの調査
5.3.3 Webサーバの使用CPUをひとまとめにする
Webサーバの子プロセスは使用するCPUが一定ではない，しかしWebサーバにCPUを使い切らせるた めに今回は使用するCPUを一つに絞って計測を行う．その操作はtasksetにより行った．tasksetは指定した PIDのプロセスが使用するCPUを割り振る事ができる．これを用いてWebサーバが使用するCPUを一つ に絞る事ができた．
以上の変更をした上でWebサーバのCPU使用率を確認した．CPU使用率の計測はmpstatを用いて行っ た．mpstatでは各CPU毎の結果を得る事ができるため，今回の実験では最適であると判断した．
5.3.4 結果検証
Webサーバの性能を引き出した状態で性能の測定を行った．Webサーバのプロセス数は同時接続数と同 値にしている．
クライアントのパラメータは--wsess=N1/10,2,1 --rateN1/10を10クライアントを同時実行し て計測した．
この時のconn/sの値を見ると次のような結果が得られた
200 300 400 500 600 700 800 900 1000 1100
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
conn/s
N1
WebServerCPU >= 100%
WebServerCPU < 100%
図25:コネクションの違いによるconn/sの変化
この図25のCPUに余裕のあるときが余裕のないときに比べ性能が良いこと，また図25の性能が落ち始 めた同時接続数(N1>=2000)の赤線部がWebサーバのCPU使用率が100%となっている事が確認できたた め，この値がサーバのコネクション性能として見る事ができると考えられる．
次にこの時得られたConnection timeの値を見る．得られた結果から以下のようなConnection time の値を取得する事ができた．
5.3 Connection timeの調査
表5:同時接続数の変化によるms/connの値の変化 Concurrent connection Connection time [ms]
500 0.23
1000 0.21
1500 0.24
2000 68.53
2500 145.50
3000 342.26
3500 725.68
4000 916.25
4500 1331.00
5000 2851.72
表5から，一定の同時接続数までは安定してる事がわかるが同時接続数2000からコネクションにかかる 時間が大幅に増加している事がわかる．同時接続1500までは安定し，その時のConnection timeは0.24[ms]
という値を得る事ができた．
しかし，得られた結果を詳しく見ると，全てのデータで1度目のデータは2度目3度目結果と比べて性能 が悪い結果が見られた．これはcacheにより2度目以降が1度目と比べて負荷がかからないためと思われる．
そのため，1度目のデータは省き，結果の変化が見られた同時接続数1500から3000のデータをより詳細 に取得する．
5.3.5 得られた結果
Webサーバの性能を引き出した状態で性能の測定を行った．Webサーバのプロセス数は同時接続数と同 値にしている．
クライアントのパラメータは--wsess=N1/10,2,1 --rateN1/10を10クライアントを同時実行し て計測した．結果はそれらで得られたConnection timeの値を全ての値を平均したものである．なお，
計測したデータは同じパラメータで3回データ取得を行い，そのうち1回目の取得データはcacheを考慮す るために省いている．
また，その時にWebサーバのCPU使用率を取得した．取得にはmpstatを用いてそれを0.1秒毎に実行 して0.1秒毎の値となっている．
図26を見ると，同時接続2400の時を境にConnection timeが増加している事がわかる．その時図 27のCPU使用率が5以下となっているものを見るとConnection timeの増加と同じようにその割合が 増加している事がわかる．以上の事からpreforkは同時接続数2300まで安定してコネクション処理を行う 事ができる事がわかる．
また，同時接続数2000の時にもCPU使用率が5%以下となっていることが見られるが，今回は誤差の範 囲とした．CPU使用率は0.1秒ごとに取得していたため，より詳細に値を取得する事ができればよりそれ らしい値を取得する事ができる可能性があると考える．
0 50 100 150 200 250 300 350 400 450
1400 1600 1800 2000 2200 2400 2600 2800 3000
conn/s
N1
perproc=N1,clients10
図26:同時接続数の変化によるconnection timeの変化
0 1 2 3 4 5 6 7
1400 1600 1800 2000 2200 2400 2600 2800 3000
100[ms]
councurrent connection if[cpu%<=5] count
図27: CPU使用率が5%以下になっているものの割合
表6:同時接続数の変化によるms/connの値の変化 Concurrent connection Connection time [ms]
1500 0.19
1600 0.20
1700 0.27
1800 0.25
1900 0.28
2000 0.30
2100 0.28
2200 0.30
Concurrent connection Connection time [ms]
2300 0.27
2400 11.56
2500 79.66
2600 200.30
2700 281.32
2800 332.16
2900 414.72
3000 444.92
6 おわりに
本研究ではApacheのmpmであるpreforkの性能調査を行い，実験環境下での性能を最大限に引き出す ような一秒あたりのコネクション数，一秒あたりのリクエスト数を得る事ができ，その調査手法を示して，
結果を記す事ができた．
Nginxについては今後詳細な調査を行いその実装についてやチューニング方法を調査する必要がある．そ
れを調べた上で適切なチューニングを行い，本研究の調査手法，実験環境，得られたApacheの性能を参考
にしてNginxの性能調査を行い，その値からApacheとNginxの性能比較を行う事を目指す．
7 付録
本研究で用いたツールやスクリプトを紹介する
7.1 httperfのインストール
7.1 httperf のインストール
この小節ではhttperfのインストールの方法を記す．
7.1.1 Unixの場合
httperfのソースをダウンロードする．
ソースは http://code.google.com/p/httperf/downloads/detail?name=httperf-0.9.
0.tar.gzここからダウンロードすることができる．
ソースのダウンロードが完了したら，ダウンロードしたファイルのあるディレクトリに移動して次の操作 を行う．
httperfインストール
✓ ✏
$ tar xzvf httperf-0.9.0.tar.gz
$ cd httperf-0.9.0
$ ./configure --prefix=$HOME/local/
$ make
$ sudo make install
✒ ✑
上記コマンドでエラーが出なければhttperfのインストールは完了である．
次に，httperfのPATHを通すために$HOMEに.bashrcを作成してPATHが通るようにする．また，.bash profile に.bashrcを読み込むように設定しておく．
bashrcに追加記述
✓ ✏
f [ -z ‘echo "$PATH" | grep $HOME/local‘ ]; then PATH=$HOME/local/bin:$HOME/local/sbin:$PATH LD_LIBRARY_PATH=$HOME/local/lib:SLD_LIBRARY_PATH MANPATH=$HOME/local/man:$MANPATH
fi
export PATH
export LD_LIBRARY_PATH export MANPATH
✒ ✑
bash profileに追加記述
✓ ✏
if [ -e ˜/.bashrc ]; then source ˜/.bashrc
✒fi ✑
この2つができたらwhich httperfによりhttperfが/$HOME/local/bin/になっている事を確 認する．