インターネットの賃貸情報は、見る価値ない

インターネトの賃貸情報サイト HOME’S や CHINTAI などに転載されている情報は見る価値はない。ここに載っている情報は、「人気がなくて載せている」 または 「いわいる囮広告 (=客付業者の客寄せ) 」です。本当に人気がある情報は、載せなくてもすぐに埋まります。

その地区から勤務先までの移動ルート・距離を調べるのには良いですが、ここに載っている情報を印刷して不動産に持っていくと、「すでに契約者がいる」 または 「実はいわくつき物件で･･･」など、他の物件を強引に勧められる可能性が高い。インターネットの賃貸情報を調べるよりも、実際に不動産に行く方が早い。

不動産の免許番号に注目する

不動産は、国土交通大臣 (1) 第 ○○○○○ 号、国土交通大臣 (10) 第 ○○○○○ 号など免許を取得してます。この括弧内の数字が大きければ大きいほど長くやっている不動産です。この免許番号は、現在は5年間ごとに1つ増えます。(1996年以前は3年間ごとに更新) つまり、(1) の場合は 5 年間未満に設立した不動産で、(10) の場合、約 40 年間 (5*3+3*7=38) やっている不動産です。

この免許番号が (1), (2) … とかは論外で、できれば (8), (10) などの不動産でお世話になるのが絶対に良い。良い物件を見つけても、(1), (2) の場合、囮広告である可能性が高い。

客付と元付の違いを理解する

賃貸物件のオーナーから直接頼まれている不動産 (=管理業者) が元付業者で、元付業者にその物件に入りたい客を紹介するのが客付業者と言う。元付業者で契約すると、仲介手数料が安くなる場合がある。しかし、管理専門でやっている業者の場合、元付業者では直接の契約を行わず、客付業者経由で契約を行うように言われる場合もある。

どちらにせよ、完全に客付しか行っていない (自分で管理している物件がない) 不動産の場合は、注意が必要である。客付業者は、客を紹介すること利益を出しているが、礼金を本来よりも上乗せしている場合や、自分への利益が多い物件しか紹介しないなど、必ず良い結果にはならない。

住む地区を検討しなおす

引っ越し貧乏と言う言葉もあるが、一度引越ししたら、できれば長くそこに住みたいと思う。繁華街に住めば、乗り換えもなく、種菌時間も短い、また遊びに行くのも良いなど利点はあると思う。もちろん人気があるので家賃が高くなる。けど、その一方、犯罪が多いと言うデメリットを理解するべきである。これは、警視庁が公開している犯罪マップを見ることをお勧めする。

これを見ると、やはり山手線沿いは、ほとんどが赤くなっており、長く住む場所としては適切ではない。1,2 本離れている地域でも中々厳しく、少し離れている場合でも快速が止まる駅は赤くなっている。お薦めは、都内に住みたい場合は快速が止まる駅の 1 本ずらした駅で、少し離れても良いなら埼玉県や、神奈川県などである。自分の場合は通勤時間は短くしたかったので、最終的に練馬区で決めた。住む予定の地域は、本当に長く住むことが出来るかを一度確認した方が良い。

地域密着型の不動産にお世話になる

基本的に山手線沿いの駅前に構えている不動産は避けた方がいい。免許番号が小さく、駅前に構えている不動産は、完全に客付けのみで、強引に契約を勧められることがある。また、大手チェーン店などは、月々のノルマがあり、どうしても契約させようという行動が出てしまう。不動産名でインターネットで検索すると、案外評判が出てくることがある。信憑性は分からないが、火の無い所に煙は立たないとも言うので、気になる書き込みがあれば避けた方が無難だろう。サービス業なので、対応が悪い不動産というのは絶対にありえない。少しでもそう感じた場合は、時間の無駄なので出た方が良い。

そのため、地域密着型の不動産にお世話になる方が良い。免許番号が大きく、対応が良い不動産は間違いない。住みたい地域の不動産情報を HOME’S (不動産を探すのには非常に便利) で検索し、免許番号の大きい順に並び替えて、インターネットで評判を調べ、2～3 件回るのが良いだろう。余談ではあるが、お互いに違う不動産を紹介しあってる所は間違いないだろう。自分の場合、最初免許番号 (10) の A 不動産で物件を探し、次に 免許番号 (8) の B 不動産に行く予定だったが、A 不動産の担当者に、「これよりも良い物件があるか B 不動産に行くと良いよ」と言われた経験がある。地域密着型の不動産は、その地域で長くやっているのでお互いに仲が良いことが多い。

朝・昼・夜と 3 回見に行く

間取りだけで判断してはいけない。もちろん内見は必ずした方が良いが、できれば朝・昼・夜と 3 回見に行ったほうが良い。通勤時間帯の朝・夜は目の前の道路が抜け道になっていて非常にうるさいなど･･･一度見ただけでは分からない事がたくさんある。

あと、日当たりも見たほうがよい。日当たりが悪い部屋は、できれば避けたほうが良い. 隣が駐車場の場合は、今後、マンションが建設される予定がすでに分かる場合もあるので、確認したほうが良い. 個人的に気にする点は、ゴミ捨て場の位置と、街灯・木の高さだ。ゴミ捨て場に近い 1 階は、ゴキブリが多い場合がある。2 階の場合は、窓を開けるとすぐに街灯がある場合は夜に虫が入ってくる場合がある。また、近くに公園がある場合は、木の高さや、夜間のバーベキューや花火を禁止しているかなどを注意したほうが良い.

賃貸物件の管理会社を調べる

良い物件が見つかり、いざ契約となる前に、その物件の管理会社の評判を調べた方が良い。今契約しようとしている業者が元付業者 (=管理会社) である場合は問題ないが、ほとんどの場合は仲介契約になると思う。その物件に住み、実際に今後お世話になるのは管理会社である。

インターネットで情報を検索し、退去時の敷金を過剰請求されたなど、電話の対応が悪いなど、そのような評判が出てくる場合は、どんなに良い物件でも辞めた方が良い。事故物件ではないが、ある意味「いわく付き物件」ではないだろうか。一度良い物件候補を見つけたが、管理会社の評判が悪くて選択肢から外した経験がある。

契約する時期

不動産は、一般的に 1～3 月が一番忙しく、この時期に行くと、ゆっくり物件を探すことが出来ない。人気物件は一瞬で埋まり、人気があまりない物件でも埋まっていく。この時期を過ぎる 4～6月は、今後も誰も契約せずに空き物件になる可能性が高いので、値段交渉がしやすい。しかし、一番忙しい時期に誰も入らなかった物件は、なにか理由がある場合が多い。6～12 月頃は、物件の数は少ないが、掘り出し物が多い。値段交渉もしやすく、一番良い時期ではないだろうか。

悪徳不動産の場合、11,12月頃に物件を探していると、「1～3月になると、大家さんも強気になって家賃を上げる事があります、今が契約するチャンスですよ」 と言う場合がある。しかし、これは早く契約させるための大嘘である。忙しくなるのは確かだが、大家さんが家賃を上げることは無いと思って良い。あえて言うなら、値引き交渉がしにくい時期である。

申込書を書いた後の値引交渉

最後に値引交渉だが、行わない人が結構多くて驚いているのだが、必ずした方が良い。契約する時期にもよるが、5000円引きになる可能性もある。かなりの人気物件でない限り、1000～2000円の値引きが成功する可能性は高い。2年間で考えると、5000 円の場合 12万円、2000円の場合、約 5 万円が浮く計算になる。また、元付け業者の場合は、必ず仲介手数料を交渉するべきである。元付業者にとって、仲介手数料は、客付業者経由での契約の場合は入ってこないお金なので、結構高い可能性で交渉できる。

値引交渉のタイミングだが、担当者と仲良くなり、いよいよ申込という段階で行うのが良い。大家さんから見ても、どのような人が入ってくるのか分からないのに、値引きをするわけにはいかない。すべては担当者にかかっているので、担当者と仲良くなり、申込書類をかき、本当に最後にお願いしてみると成功する可能性は高いと思う。

番外編として、申込書を書く前に、担当者の方から値引きの話をしてくる場合もある。これは免許番号が小さい不動産に多く、実は、最初に間取り図を見せてもらう段階で既に家賃が釣り上げられている可能性がある。そして値引交渉できました～と言い、実際は本当に家賃になっただけ･･･という。悪徳不動産には要注意だ。

まとめ

経験談も含めて書いたので長くなってしまったが、重要な点は次の3点だ。

• 免許番号が大きい、地域密着型の不動産にお世話になる。
• 犯罪マップで、その地域に長く住むことができるかを調べる。
• 値引交渉は、担当者と仲良くなり、申込書を書いた後で丁寧にお願いする。

あまり構成を考えずに書いてしまったので、そのうち書きなおすと思う。読みにくくて申し訳ないが、良い物件を見つけるために参考になれば幸いです。

コマンド

新しい DB および ユーザーの作成コマンド

入力ファイルのリクエスト順番

--wsesslog=N,X,F では、F ファイルに記述した順番で、リクエストを送信する。次のような入力ファイルの場合を考える。

この場合、1 セッションで合計 7 ページにリクエストを送る。また、必ず index.html, 1.gif, 2.gif, ... 7.gif の順番で処理を行う。

もし、サーバー側の MaxKeepAliveRequests などの設定によって、処理を行っている途中で connection-reset エラーが発生した場合も、エラーで処理できなかったファイルに再度リクエストを送り、正常に reply を受け取った事を確認してから、次のファイルにリクエストを送る。リクエストを送る順番が変わることなく、正しくログを再現する。

この入力ファイル F の 1 バーストの長さは 7 なので、--wsesslog を使わない場合の --num-calls=7 と、ほぼ同等とも言える。

httpd.conf 抜粋

モジュールに関する部分のみ抜粋して表示する。なお、モジュールの説明コメント (// 以降) は、実際に設定するときは削除しないと起動しないので注意。

速度測定

チューニング前

チューニング後

Request rate: 7.2 req/s が 7.4 /req/s に向上している。誤差の範囲とも取れるので、気休め程度だけど･･･効果あるはず？

参考文献

モジュール一覧 - Apache HTTP サーバ
http://httpd.apache.org/docs/2.2/ja/mod/

導入

APC を pecl でインストールする。

APC の設定ファイルを作成する。これはパフォーマンスを重視した設定内容のため、注意する事。

APC のステータスを Web 上から確認するスクリプトへのリンクを張る。また、デフォルト値の状態だと認証できない為、認証情報を修正する。

APC を実行し、設定内容を確認する。

http://IP/apcinfo.php に接続し、設定した認証情報で表示できるか確かめる。また、APC の設定項目で apc.stat=0 を行っているため、PHP スクリプトを編集した場合も、APC による編集前のキャッシュが実行される。そのため、ファイル更新を行うには Apache の再起動を行い、古いキャッシュを削除する必要がある。

関連文献

PHP: APC - Manual
http://www.php.net/manual/ja/book.apc.php

MySQL のクエリーキャッシュ

デフォルト状態では、クエリーキャッシュが有効になっていないため、有効にする。動作を確認する為に実行されたクエリーをファイルに保存する。クエリーキャッシュを有効にした直後のアクセスと、2 回目のアクセスでどのような変化があるかを調べる。

1 回目のアクセスで 22 回のクエリーが実行された事が分かった。その内、16 クエリーがキャッシュに保存された。(クエリーに保存されるのは、SELECT 文のみ) 2 回目のアクセスでは、同じページへのアクセスなので、前回同様に 22 回のクエリーが実行された。その内、16 回のクエリーがキャッシュに保存された内容と一致し、キャッシュから返された。クエリーを有効にすることで、多少の高速化が見込めそうだ。

WordPress 標準のキャッシュ機能

WordPress には標準でキャッシュ機能がある。

WordPress 2.5 より、この機能が削除された。

memcached による分散キャッシュ

memcached は高性能な分散メモリキャッシュサーバで、データベースへのクエリー結果を一時的にキャッシュできる。MySQL のクエリーキャッシュの場合は、実際に問い合わせが発生するが、memcached の場合は問い合わせが発生しない。memcached は分散キャッシュサーバなので、複数のサーバで構築する事も出来るが、今回はlocalhost で memcached にアクセスできるように WordPress をインストールしたサーバに memcached を同居させる。memcached を有効にした直後のアクセスと、2 回目のアクセスでどのような変化があるかを調べる。

次に WordPress に取り込むために object-cache.php をダウンロードし、./wp-content/object-cache.php として設置する。

http://ryan.boren.me/2005/12/23/memcached-backend/
http://plugins.trac.wordpress.org/browser/memcached/trunk/object-cache.php

WordPress と memcached が同じサーバーの場合は特に設定は必要ないが、異なるサーバーの場合は、wp-config.php に追記する必要がある。

必要ではないが、便利なツールとして memcache.php がある。これを設置すると、memcache でキャッシュしているサイズを表示する事ができる。

http://livebookmark.net/journal/2008/05/21/memcachephp-stats-like-apcphp/
http://livebookmark.net/memcachephp/memcachephp.zip

memcached が動作しているサーバと、接続するのに必要な認証情報を編集する必要がある。

memcache.php を開くと、現在のキャッシュ容量が Used: 0 KBytes (0.0%) と表示されていれば正常。準備は整ったので、実際に memcached を動作させ、アクセスする。

memcache.php を確認すると、17 クエリー (Current Items 17) がキャッシュに保存されており Used: 18.7 KBytes (0.0%) となっている。MySQL のクエリーキャッシュには 16 クエリー保存されている。

2 回目のアクセスでは、memcached のキャッシュに保存された内容と一致し、最終的に 11 回のクエリーが実行された。その内、5 クエリーが MySQL キャッシュに保存された内容と一致し、キャッシュから返された。大幅に減少しており、かなりの高速化が見込めそうだ。検証する為に設定したクエリーの全文保存は、負荷が増加する為、通常運営時は無効にする。

パフォーマンス測定

httperf を使って、チューニング後のパフォーマンスを測定する。生成する負荷は、WordPress の 1 ページ (?p=3) に X={1,5,10.20.50} 人 (--rate=X) が同時にアクセスして、合計 100 回 (--num-conns=100) 表示されたらベンチマークを終了する。Apache の設定はデフォルト値とする。

チューニング後の測定結果のポイントとなる点を以下に示す。

--rate=1 のときは、1 リクエストあたりの平均 response 448.6 [ms] で、まだまだサーバに余裕がある。--rate=5～50 をみると、Request rate が 4.5～4.7 req/s となっているため、サーバに余裕が無い状態を示している。MySQL への同時コネクション数は、初期設定では最大 100 だが、測定結果の Max_used_connections をみると、最大 25 となっている。このため、まだまだ MySQL 側には余裕があるがサーバからのリクエストが届いていない状態を表しており、MySQL 側がボトルネックになっている可能性は低いと考えられる。

OUTPUT

このセクションは、各テストの終わりの統計出力について説明します。次に示された基本情報は、負荷生成のオプションに関わらず表示されます。

Total: connections 30000 requests 29997 replies 29997 test-duration 299.992 s
　
Connection rate: 100.0 conn/s (10.0 ms/conn, <=14 concurrent
connections)
Connection time [ms]: min 1.4 avg 3.0 max 163.4 median 1.5 stddev 7.3
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 1.000
　
Request rate: 100.0 req/s (10.0 ms/req)
Request size [B]: 75.0
　
Reply rate [replies/s]: min 98.8 avg 100.0 max 101.2 stddev 0.3 (60 samples)
Reply time [ms]: response 2.4 transfer 0.0
Reply size [B]: header 242.0 content 1010.0 footer 0.0 (total 1252.0)
Reply status: 1xx=0 2xx=29997 3xx=0 4xx=0 5xx=0
　
CPU time [s]: user 94.31 system 205.26 (user 31.4% system 68.4% total 99.9%)
Net I/O: 129.6 KB/s (1.1*10^6 bps)
　
Errors: total 3 client-timo 0 socket-timo 0 connrefused 3 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

6 つのグループがあります。総合的な結果の `Total`、コネクションに関係した結果の `Conection`、HTTP リクエストに関係した結果の `Request`、サーバから受け取った回答に関する結果の `Reply`、CPU に関係する多方面の結果の `CPU`、ネットワークの利用の `Net I/O`、最後に大切な内容となるエラーに関する要約の `Errors`です。

Total Section

このセクションは何個の TCP コネクションが httperf によって開始されたか、何個のリクエストを出したか、何個のリプライを受け取ったか、テストにかかった時間は何秒か、をまとめています。上の出力結果の例の場合では、3 万コネクションが作成され、2 万 9997 リクエストを送信し、2 万 9997 リプライを受け取り、テストにかかった時間は、ほとんど正確に 5 分 (300秒) でした。

Connection Section

このセクションはツールで生成される TCP コネクションに関する情報を伝えます。明確に、`Connection rate` 行は、新しいコネクションが1 秒あたり 100.0 のレートで開始された事を示しています。このレートを言い換えるとは、1 コネクションあたり 10.0 ミリ秒です。この行の最後の数は、いつでも 14 コネクション開かれていた事を示します。

最初の行の `Conection time` ラベルは、成功したコネクションのライフタイムの統計です。コネクションのライフタイムは、TCP コネクションが開始された時間と、コネクションが閉じられた時間の、間となります。A connection is considered successful if it had at least one call that completed successfully. 出力結果の例の場合では、最小のコネクションライフタイム (min) は 1.4 ミリ秒、平均 (ave) は 3.0 ミリ秒、最大 (max) は 163.4 ミリ秒、中間 (midian) は 1.5 ミリ秒、標準偏差は 7.4 ミリ秒を示しています。The median lifetime is computed based on a histogram with one millisecond resolution and a maximum lifetime of 100 seconds. Thus, the median isaccurate to within half a millisecond if at least half of thesuccessful connections have a lifetime of no more than 100seconds.

このセクションの次の統計値は、TCP コネクションが確立するのにかかる平均時間です。成功した TCP コネクションの確立のみを数えます。出力結果の例では、2 行目の `Connection time` が示し、コネクションが確立するのに平均 0.6 ミリ秒かかりました。

このセクションの最後の行 `Connection length` ラベルは、少なくても 1 つの回答を受け取った各コネクションで、受け取った回答の平均値を示します。つまり、最初の回答を受け取る前に失敗したコネクションはカウントしません。この数は、持続するコネクションの場合 1.0 より大きい場合があります。

Request Section

`Request rate` は、HTTP リクエストが出されたレートを示します。出力例の場合では 1 秒あたり 100.0 リクエスト出された事を示しています。このレートを言い換えると、1 リクエストあたり 10.0 ミリ秒です。持続するコネクションを有効にしていない限り、このセクションの結果は、コネクションセクションの結果と、同じ・または非常に似ています。しかしながら、持続する接続が有効の場合、1 つのコネクションで複数のリクエストを実行できます。その場合、これらの結果は異なっているでしょう。

`Request size` は HTTP リクエストの平均サイズ (bytes) を示しています。出力結果の例の場合では、平均リクエストサイズは 75 bytes です。

Reply Section

`Reply rate` は、様々なリプライレートの統計を示します。簡易測定のために、このセクションはしばしば最も面白いです。出力結果の例では、最小 (min) リプライレートは 1 秒あたり 98.8 回、平均 (avg) は 1 秒あたり 100 回、最大 (max) は 1 秒あたり 101.2 です。括弧の中の数は 60 個のサンプルを取得した事を示しています。現在は httperf は 5 秒に 1 個のサンプルを取得します。重要な標準偏差を得るために、十分長いテストを行う事が勧められるので、少なくても 30 個のサンプルを取得します。これは、少なくても 150 秒のテストを行う事に相当します。

`Reply Time` は、そのサーバからの応答にどれくらかかったかと、そのリプライを受け取るのにどれくらいかかったかを示します。出力結果の例では、最初のリクエストを送ってから最初のリプライを受け取る間 (response) は、平均 2.4 ミリ秒です。transfer はリプライが測定するためには短すぎる場合は、0 と表示されます。典型的には、連続したリプライが 1 つの TCP セグメントに収まります。

`Reply size` は、リプライの平均サイズ (byte) を示します。正確に言うと、リプライヘッダー、コンテンツ、フッター (HTTP/1.1 は Chunked Transfer-Encoding を使用します) の平均長さです。括弧では、各平均値の合計を示しています。出力結果の例では、ヘッダーの平均長さ (header) が 242 byte、コンテンツの平均長さ (content) が 1010 byte、フッターの平均長さは 0 byte です。また、リプライ全体の平均長さは 1252 byte です。

このセクションの最後の行は、サーバからリプライで受け取った主要なステータスコードのヒストグラム (度数分布図) です。主要なステータスコードは完全な HTTP ステータスコードの数百桁です。出力結果の例では、全ての 2 万 9997 回のリプライが主要なステータスコード 2XX を持っていました。良い方の推測をすると、全てのステータスコードが 200 OK である事です。しかし、ヒストグラムによる情報は同じ主要なコードでステータスコードを区別するのを許容するくらいには詳細ではありません。

Miscellaneous Section

`CPU time` はクライアントマシンの CPU 使用率のサマリーを示します。出力結果の例では、`CPU time` は、ユーザーモード (user) の実行に費やされた時間が 94.31 秒、システムモード (system) の実行に費やされた時間が 205.26 秒です。ユーザーモードの実行が 31.4%、システムモードの実行が 68.4% に相当します。また合計 CPU 使用率が 99.9% で、httperf は CPU に貪欲であることが予想できます。合計 CPU 使用率が 100% 未満である場合は、テストを妨げた競争しているプロセスがあったという重要なサインです。

`Net I/O` は、1 秒あたりの Kbyte (1kbyte=1024bytes) と、1 秒あたりの Mbit (1Mbit=10^6bits) における平均ネットワークスループットを示します。出力結果の例では、1 秒あたり約 129.6 Kbytes の平均してネットワーク帯域を使用しています。括弧の数は、これが 1 秒あたり約 1.1 Mbit に相当する事を示しています。このネットワーク回線帯域は、TCP コネクションのときに送られて、受け取ったバイト数に基づいて計算されます。言い換えれば、発生したかもしれない TCP 再送信またはネットワークヘッダーの account? になりません。

Errors Section

最後のセクションでは、テストを行っている間に発生したエラーの統計を示します。出力結果の例では、2 行の `Error` ラベルで、合計 3 個のエラーが発生し、3 個全てのエラーがサーバがコネクションの受け入れを拒否 (connrefused) した事を示しています。各エラーの詳細を以下に記述します。

client-timo: クライアントタイムアウトのために呼び出しが失敗した回数。クライアントタイムアウトオプション (具体的に --timeout と--think-timeout) が正当であるか確認してください。

socket-timo: TCP コネクションがソケットレベルでタイムアウトした回数 (ETIMEDOUT)

connrefused: サーバによって拒否されたコネクションエラーに応じて失敗された TCP コネクションの回数 (ECONNREFUSED)

connreset: サーバからの RESET のために失敗した TCP コネクションの回数。通常、サーバが既にコネクションを閉じたときに、クライアントがデータを送る試みを行うと RESET を受け取ります。listen queue が一杯のとき、新しいコネクションの確立を試みるとき、NT サーバは RESETs を送ります。

fd-unavail: httperf プロセスがファイルディスクリプタを使い果たした回数。このカウントが 0 以外の場合はクライアントがオーバーロード状態であり、テスト結果が無意味である事を示します。(fd-unavail エラーの場合、コネクションを再生成できないため正統性が失われる) 詳しくは CHOOSING TIMEOUT VALUES セクションを見てください。

addrunavail: 存在しないインタフェースが要求されたか、要求されたアドレスが ローカルではなかった回数。もしこのエラーが発生した場合は、テスト結果が無意味である事を示します。(EADDRNOTAVAIL)

ftab-full: システムのファイルディスクリプタテーブルの上限に達した回数。もしこのエラーが発生した場合は、テスト結果が無意味である事を示します。(ulimit -n で上限値を上げる対策が考えられる)

other: 上記以外のエラーが発生した回数。このカウントが 0 以外の場合は、エラーの本当の原因を探し出す必要があります。これを助けるために、httperf はテストの間に起こる最初の未知のエラーコードを表示します。

--wsess オプションまたは --wsesslog オプションが指定された場合、httperf はコネクション呼び出しの代わりにセッションを精製して測定します。そして、テストの終わりに追加情報を表示します。実際の表示例を以下に示します。

Session rate [sess/s]: min 0.00 avg 0.59 max 2.40 stddev 0.37 (240/450)
Session: avg 6.45 connections/session
Session lifetime [s]: 123.9
Session failtime [s]: 58.5
Session length histogram: 4 7 4 ... 3 3 240

1 つのグループがあります。セッションに関係した結果で、`Session rate`、`Session`、`Session lifetime`、`Session failtime`、`Session length histogram` の 5 つの項目です。

Session Section

`Session rate` は、セッションが完了したときの 5 秒間隔のサンプルに基づいた最小、平均、最大のレートを示します。また、それはセッションの標準偏差を示します。括弧内の数は、いくつのセッションを行い、その内いくつのセッションがい成功したかを示しています。実際の例では、1 秒あたりの最小が 0.00、平均が 0.59、最大が 2.40、標準偏差は 0.37 でした。450 セッションの内、240 セッションが完了しました。210 は、タイムアウトなどのエラーのために失敗しました。

`Session` は、1 セッションの平均コネクション数を示します。実際の例では、1 セッションが完了するのに、平均 6.45 コネクションを必要とした事を示しています。

`Session lifetime` は、成功したセッションが終了するのに要した平均時間を示します。実際の例では、1.23.9 秒かかったことを示しています。

`Session failtime` は、失敗したセッションの平均時間を示します。実際の例では、セッションが失敗するには平均 58.5 秒かかったことを示しています。

最後に、`Session length histogram` は、各セッションで受け取ったリプライ数のヒストグラムを示します。実際の例では、4 セッションが終了した後に、In the example above, 4 sessions ended after receiving no reply at all, 7 ended after receiving one reply, and so on (the ellipsis indicates additional histogram counts that were omitted from this manual for space reasons). このヒストグラムが成功したセッションと失敗したセッションを区別しないことに注意してください。

参考文献

httperf-man-0.9.pdf
http://www.hpl.hp.com/research/linux/httperf/httperf-man-0.9.pdf

日時を表示

実は色々と奥が深いコマンド！
シェルスクリプトを書くときにかなり便利。

date_micro コマンド

以上

テスト環境

10.0.0.1 サーバで Apache + PHP (module) を動作させる。また、10.0.0.2 サーバで MySQL を動作させる。各サービスの設定項目はデフォルト値とする。最後に、10.0.0.3 サーバで httperf を動作させ、WordPress に対して負荷を生成する。

各サーバは CPU 3.6GHz Quad-Core、RAM 2048MB, SCSI 32GB で構成されている。各サーバは 1000BASE-T の単一スイッチで接続されている。ハードウェア性能、ネットワークがボトルネックになる心配はないと思う。

WordPress は version 2.8.4 で、設定項目はデフォルト値とし、デフォルトのテンプレートを使用する。適当な文字列のみを投稿した 1 ページに対して調査する。

1 ページを表示するのに必要なリクエスト

通常 WordPress に接続すると、デフォルトのテーマの場合 7 ファイルに接続している。これはアクセスログを見れば明らかで、具体的に示すと、以下のファイルである。これらのファイル群をまとめて、「バースト」と呼ぶ。

response time [ms] の測定

バーストを表示するのにかかる response time [ms] を測定する。

上記結果から、1 リクエストあたりの平均 response time [ms] は、63.5 と分かった。1ページを表示するのにかかった response time [ms] は、444.5 (63.5*7) である。また、バーストの中で "/WordPress/?p=3" ファイルのみの response time [ms] を測定する。

上記結果から、437.9 とわかった。このように、バーストの中で圧倒的にリクエスト時間がかかるのが、"/WordPress/?p=3" である。他のファイルは static なので特に処理は必要ないが、"/WordPress/?p=3" はデータベースへの問い合わせが発生している。具体的にどんな問い合わせが発生しているのかを調べてみる。

1 ページを表示するのに発生するデータベースへの問い合わせ

MySQL の設定項目はデフォルト値となっており、次のようになっている。

クエリー内容を調べるために、以下の処理を行う。

httperf で "/WordPress/?p=3" ファイルのみにリクエストを出す。

/var/log/mysql-all.log ファイルを確認する。

1 ページを表示するのに、20 回のクエリーが発生している。思っていたよりも多い結果だと思う。すべてのクエリーを保存するのはパフォーマンスを悪化させるため、設定ファイルを戻しておく。

負荷が高い状況での response time [ms]

同時に 1 人が WordPress のページを表示している状況の場合の response time [ms] を測定する。本来ならバースト全てのファイルでやるべきだが、バーストの中で一番処理時間がかかる "/WordPress/?p=3" ファイルのみにリクエストを出す。

同時に 5 人が WordPress のページを表示している状況の場合。

同時に 10 人が WordPress のページを表示している状況の場合。

同時に 20 人が WordPress のページを表示している状況の場合。

同時に 50 人が WordPress のページを表示している状況の場合。

上記結果をまとめると、このようになる。

上記結果から --rate=10 を超えると Max_used_connections があまり増えなくなっている事が分かる。この値は、MySQL への同時コネクション数を示している。また、MySQL のデフォルト値では、同時コネクション数は最大 100 になっている。

つまり、10.0.0.1 サーバの Apache + PHP 側がボトルネックになっている可能性が高いと考えられる。それを確かめるために、MySQL で1 秒以上処理時間がかかるクエリーがある場合、ログファイルに書き出す設定を行う。

上記結果から、1 秒以上処理時間がかかるクエリーは無い事が分かった。

どこをチューニングすれば良い？

チューニングポイントの候補としては、(1) Apache, (2) WordPress (3) MySQL, (4) PHP だと思う。

まず、(1) Apache だが、今回の測定結果から現在の状態では Request rate: 4.7 req/s が上限となっていることが分かった。つまり、同時に 4.7 人以上の接続があると、サーバに余裕がなくなり徐々に Request rate が低下していくと予想できる。そのため Apache の MaxClient を極端な値にすると 5 とか、20 に設定することで現時点での最高の Request rate でリクエストに答えることができる。しかし、Request rate: 4.7 req/s は、かなり低い数字だと思うので、この Request rate を上げるためのチューニングを行いたい。

そのために 1 ページを表示するのに 20 回のクエリーを実行している (2) WordPress 本体を改造する方法があると思う。こちらのサイト

WordPress チューニング
http://WordPress.rauru-block.org/index.php/1589

を読むと、やはり無駄なクエリーが多数あるようで、最終的に 4 回のクエリーで表示させれるようになるようだ。(これは凄い！凄く効果がありそうだ) 他には、こちらのサイト

WordPressが重くなる理由わかった～結局さくらサーバ移転へ｜高橋文樹.com
http://takahashifumiki.com/web/603/

によると、プラグインで外部 Web サービスに接続しているのがボトルネックとなっている場合も多いみたいだ。今回の測定では外部 Web サービスに接続を行うようなプラグインは使用していない (デフォルトで組み込まれているプラグインのみ) ので関係ないが、一応紹介しておく。しかし、WordPress 本体を改造するのは、少し敷居が高くなるので今回は行わない。

その代わり、(3) MySQL のクエリーキャッシュと、memcached による分散キャッシュサーバを用いる事で、クエリーの負荷を減らす方法がある。なかなか面白い内容なので別のページにて紹介したいと思う。しかし、今回の測定で、恐らく MySQL よりも Apache+PHP 側がボトルネックになっている可能性が高いと考えられる。

最後に、(4) PHP のチューニングがある。PHP はスクリプト言語のため実行する度に機械語に変換するコンパイル処理が発生している。これは非常に重たいため APC（Alternative PHP Cache）モジュールを導入することによって、PHP の中間コードのキャッシュや最適化を行うことができる。なかなか面白い内容なので別のページにて紹介したいと思う。

man 日本語訳

--wsesslog=N,X,F

これは、--wsess と同様にセッション負荷生成を指定します。--wsesslog を用いると、URI のシーケンスと数、リクエストメソッド、think-time と burst-length パラメーターを含む、多数のユーザーセッションの特徴を、入力ファイル F に指定できます。--wsess と同様の 2 つのパラメーターがあり、N は生成するセッション数で、X は burst と burst 間の user think-time です。user think-time は、入力ファイル F でも指定できるので、この X はデフォルト値となります。簡単な入力ファイルの例で、設定できるパラメーターを示します。

上の例では、2 つのセッションを指定しています。1 つ目のセッションは、/foo.html に対してリクエストを出します。この /foo.html のレスポンスが返ってきたときに、バーストの /pict1.gif と /pict2.gif の 2 つのリクエストを出します。これらのリクエストが返ってきたときに、user think-time 2.0 秒間待機します。その後、/foo2.htmlに対してリクエストを出します。このリクエストは POST メソッドを送信します。POST されたデータは、シングルまたはダブルクオーテーションで囲みます。この /foo2.html のレスポンスが返ってきたときに、バーストの /pict3.gif と /pict4.gif のリクエストを出して、このセッションを終わります。

2 つ目のセッションは、--wsesslog オプションの X パラメーターで指定された user think-time のデフォルト値で区切られた 2 つのリクエストから成ります。もし、--wsesslog オプションの N パラメーターが入力ファイル F で定義したセッション数 (今回の場合 2 セッション定義している) より大きいなら、定義したセッションを N セッション作成されるまで繰り返し使用します。

セッションの振る舞いを制御する httperf のオプションを --wsesslog と一緒に使用するのを避けるべきです。URI のワークロード、すなわち、--burst-length、--wsess、--wlog、--wset オプション。

入力ファイルの例

バーストとセッションが出てくるが、簡単に言うと、

例えば、wordpress の /?p=1 ページに開いた場合、関連する合計 7 ファイルがダウンロードされるので、これら一連のファイルをバーストと呼ぶ。単純に /?p=1 ページを開いてサイトを去った場合の、1 バースト、1 セッションを入力ファイル wplog に記述すると、このようになる。

少し付け加えて、/?p=1 ページを開いた 10 秒後に、/?p=2 ページを開いて、その後 /?p=3 ページを開いてサイトを去った場合の、3 バースト・1セッションを入力ファイル wplog2 に記述すると、このようになる。

その後、別のサイトに接続した場合の、4 バースト・2 セッションを入力ファイル wplog3 に記述すると、このようになる。

実際のコマンド例

例えば、入力ファイル wplog3 を指定して、合計 4 セッション生成する場合、このようになる。

通常、バーストの一連のファイルはサーバー側の KeepAlive によって 1 つのコネクションで処理される。また、上記結果からわかるように、各セッションごとに新しいコネクションが作られている。今回は 1 セッションにつき 1 コネクションで処理が完了しているが、入力ファイルのバーストが多い場合、またはサーバー側の KeepAlive の各設定値によっては 1 セッションにつき複数のコネクションが必要な場合もある。なお、サーバー側では、このようなログが記録されている。