サーバの待ち時間を計測したいです
■ このスレッドは過去ログ倉庫に格納されています
0001素人
NGNG計測したいんです。
普通はpingを使うのかもしれませんが、pingの遅延時間
(数百msオーダー)と実際の待ち時間(数秒オーダー)の相関が
はっきりしないことがあるので、pingでなくもっと実際に即した方法で
計測したいです。
だからといって、ストップウォッチを手にもって手動で測るのは
スマートなやり方ではありません。
業界の方々の意見を聞きたく存じます。
0002Five
NGNG定期的に実行し、結果を MRTG のデータファイルにすると結構いいかも。
# Java や Tcl/Tk＠｀ Python＠｀ Ruby 何でもいい。
MRTG のデータファイルの作り方については、今月号の Software Design を
参照するといいでしょう。
0003Five
NGNG異なるからです。このため、ベンチマークを取るときは、漫然と数字を取るのではなくて
（ただ数字を取るだけのときもあるけど）、負荷モデル（Load model）を意識して数字を
取るべきです。
# 実際にはある程度大きな組織でちゃんとした人がマネージャのときにのみ実施される
ことが多い。
（続く）
0004Five
NGNG・クライアントからサーバーに ICMP Echo Request が送信
・カーネルで ICMP の処理を実行
・サーバーからクライアントに ICMP Echo Reply が送信される
という処理が行われます。
それに対して、POP3 の場合には、
・クライアントはサーバーと TCP Session を確立
・inetd から qpopper が起動
-> カーネルでプロセスを新たに生成
・qpopper は認証を実施（-> Kernel に認証を依頼）
-> カーネルは認証を実施
・メールファイルを /tmp にコピー（ここが一番負荷がかかる）
-> /var/mail の適当なファイルを /tmp にコピー
・コマンドごとに適当な処理（DELE が一番面倒）
-> qpopper は /tmp の一時ファイルを変更・削除
・終了処理
-> /tmp から /var/mail に書き戻す
-> TCP Session を終了
といった一連の処理が実施されます。このように、プログラムの挙動を分析し、
負荷がかかるポイントを抽出してモデル化する作業のことを「負荷モデルの作成」と
言います。ベンチマークの価値は、この負荷モデルがどこまで現実に近いか、そして
この負荷モデルの各ポイントに関してどれだけ有意な結果を取得できるかにかかって
います。
# ある意味では負荷モデルの伴わないベンチマークは自己満足以上の意味を持ちません。
（続く）
0005Five
NGNG与える負荷が大きくなります。ping の数字と実際の体感の違いはここから出てきます。
さらに、上記過程のどこで一番大きな負荷がかかっているかを調べます。そのために
いくつかの手段をとります。
・まず、プロセス生成、ファイルのコピー（ディスクI/O）といった個別の要素ごとに
簡単なベンチマークを実施して、それぞれの数字を取ります。
・次に、上記過程を意識してどの過程にどのくらいの時間がかかるかの、仮説を
立てます。
・上記仮説による結果と実際の結果を比較して、モデルに検討を加え、最終的に
実際の結果とモデルが近くなるようにモデルを改良していきます。
こうして、当初の仕様（POP3 で接続まで n 秒以内であること、とか）を満たすことが
可能であるか否か、可能だとして現在がどのくらいの数字で、メールサイズや
同時接続数に応じてどのように応答性能が劣化していくかについて、実際の数字を
得ることが出来ます。
# これによって、現在の機器の性能限界なども理解することが出来ます。例えば、
ディスク I/O の平均性能が 1MB/sec であり、平均ユーザーのメールボックス
サイズが 100KB だとすると、応答性能1秒を満たすためには同時接続が
10 ユーザー以下であることが必要です。普通はこういう四則演算のレベルで
十分です。微分方程式や確率を使ったモデルはまず作りません。複雑すぎると
得られるメリットよりも手間の方が大きくなってしまうので。
（続く）
0006Five
NGNGですが、WWW の場合にはかなり難しくなります。というのも、ロードモデルが
上記のように一つだけでなく、
・静的ページの要求
・動的ページの要求
の最低2種類が必要であり、さらに動的ページについてはデータベースなども
関連してきて非常にロードモデルが複雑になるからです。静的ページでも、
・各ページごとのサイズ及び同時に読み込まれるファイル（画像等）が異なる
・各ページごとに読み込まれる頻度が異なる
ということでこれまた簡単にはいきません。
通常は、アクセスログを解析してアクセスパターンを理解し、それをもとに
・ページへのアクセスの結果どれだけの負荷が発生するか
・そのパターン及び分布はどうなっているか
を分析し（CGI の場合には、独自にログを残すようにしておく必要がある）、
それによって負荷モデルを構築しベンチマークを実施してシステムの性能を
把握することになります。この辺はまだまだノウハウの蓄積が少ない
（少なくとも外部に十分に公開されていない）分野です。
個人の趣味でやる範囲ではここまでしませんが、仕事として発注された場合には
そこまで意識して設計することになります。1 の人がどのような環境で計測
されるのか分かりませんが、もし業務として実施するのであれば、ぜひ一度
簡単にでもよいので負荷モデルを作ってみて、その上で数字を取ってみると
よいと思います。今までブラックボックスだったサーバーの中が、だんだん
理解できるようになってきますので。
では、頑張ってください。
00071
NGNGWWWの場合はとても難しいんですね。私はtcpの転送シーケンスの
知識とmrtgの設置経験くらいしか無いのですが、Fiveさんに
お教えいただいたことを元にして自分で勉強してみたいと
思います。
ありがとうございました。
0008Five
NGNG「実践的 Web マーケティング論」ブキャナン他著（翔泳社）
が非常に参考になると思います。また、パフォーマンス解析関連では
データベース関連書籍を参考にするとよいと思います。
「Oracle8 パフォーマンスチューニング」（これも翔泳社だ・・）
なんて読んでおくと、どういうところがボトルネックになりやすく、また
それを解決するためにどんな技術があるのかを知ることが出来ます。
以上、参考までに。
0009two
NGNG>異なるからです
当然ですが、クライアント側の処理も違いますし(インラインイメージやJavaやキャッシュ)
、回線の利用状況も異なります。(コネクションを何本も張ったりする。)
一応...
私の場合、WEBが重いなーと思ったときの典型的な行動パターン
はこんな感じでしょうか...
●pingしてみる
=>遅い場合
●tracerouteしてみる
=>こちら側が遅い場合
●こちらプロバイダに文句
=>相手側が遅い場合
●WEBページ管理者を通じてプロバイダに文句
●wgetしてみる
=>遅い場合
●同じサーバの他のページをwgetしてみる
=>遅い場合
WEBサーバ管理者に文句を言う
=>速い場合
WEBページ管理者に文句を言う
●IEで取得してみる
=>遅い場合
●Netscapeと比較してみる
=>速い場合
●Microsoftに文句を言う
●Microsoft依存部分を使わないようにしてもらう。
●Proxyなどを利用して接続ログを残す
=>特に時間がかかっている所があるか
●その接続の発生原因を探す
●tcpdumpしてみる
=>パケットの流れが変
●OSが変??
0010Five
NGNGアプリケーションではクライアントの方がボトルネックになるケースも
多いです（よく見ます）。これに言及し忘れたのはひどいミスです。ごめんなさい。
# 最近かなりボロが出てきましたね。とうとう本性が明らかに・・・。
もと質問が
> サーバがどれくらい重いのか、待ち時間を計測
とあったので、すっかり見落としていました。といっても 1 さんの責任では
ありません。指摘し忘れた自分の責任です。
で、クライアントについてもきちんと書くと、サーバーと同様に負荷モデルの
記述が必要になります。POP3/ping の場合には、単純なので大して考えなくても
よいのですが（これがモデルからクライアントを見落した最大の原因でした）、
例えば Web アプリケーションの場合には、
・HTML コンテンツを取得
・HTML の解析および構造の取得
・必要な追加コンテンツを取得（CSS 定義ファイル、フレーム要素、
イメージ、Java Applet 等）。
またそれと平行して画面イメージの生成
（TABLE 多数 & ネストしているとこれにかなり時間を取られる。最悪の場合には
ブラウザクラッシュ）
・最終的な画面表示（ほぼ一瞬）
という過程を経て最終的な見栄えが構築されることを考慮して負荷モデルを記述
します。このモデルを考慮しながら最終的なアプリケーションを構築する
ことになります。
# CD-ROM 1＠｀2 倍速時代に CD-ROM コンテンツを作っていましたが、このときも
転送レートを考慮しながらそれを超えないようにアプリケーションを作って
いました。このように、クライアントの負荷モデルはインターネットや企業での
アプリケーションに限定されるものではありません。
0011Five
NGNGというのも、サーバーは割と問題点があっても改善しやすいのですが
（サーバーのオーナーがうんと言えばよい）、クライアントの場合には
「あなたのブラウザのバージョンの問題です。他のブラウザにしてください」とか
「もっと速いマシンで見てください」という結論に達した場合にどうしようも
ないからです。企業内システムの場合には何とかなるケースもありますが
（しかしアップグレードや配布コストの関係で駄目な場合が多い）、
インターネットアプリケーションの場合にはほとんど改善不能です。
せいぜいコンテンツの作り方を注意するしかない（結局、サーバー側で
対処するしかない）のが現状です。
なお、two さんの方法と自分の方法はかなり違っていますが、これは両者の
視点が異なっているせいであり、どちらかが間違っているからということでは
ありません。自分の視点は「管理者の視点」です。それに対して two さんの
視点は「ユーザーの視点」だと思います。従って two さんの図式だと
文句をいわれるほうの立場です。(^^; two さんのようなユーザーから
クレームを受けたら、上記方法で問題点を解析することになります。
自分が管理者の視点を取っているのは、「管理者が管理できない事柄は
改善の余地が無い」というスタンスを取っているからです。例えば
NSPIXP でルーティングループが発生していてサーバーに到達できず、
その結果遅延が無限大になったとしても、それは管理者からはどうしようも
ないことです。管理者ができるのは、せいぜい他の IX とも接続できるように
する程度です（ここでもコストベネフィットを考慮する必要がありますが、
それは別問題ですね）。ブラウザのバグのためにコンテンツを正しく表示できない
というトラブルについても同じです。先に述べたように、サーバー側で対処する
という発想になります。これはアプリケーションを構築する立場で解析を行って
いるという個人的事情も大いに関係しているでしょう。
0012Five
NGNGその場で即興的に考えたモデルです）を妄想して、
・コンテンツサイズと読み込みに要する残り時間（及び平均転送レート）を
計測（ないし予想）
・ping で平均的なラウンドトリップタイムを計測
・traceroute でネットワークの性能を計測（推測）
・telnet で HEAD を発行して Web サーバー自身の応答性能を推測
・コンテンツの作り方（Table が多いと表示は遅くなる等）を考慮して
クライアントの負荷を予想
・URL やコンテンツからアプリケーションの構造を予想して、だいたいの
サーバー上の I/O の負荷を予想
といった過程を経て何が原因かを考えることが多いです。
で、2ch は Web サーバー自体はそんなに重くないね、という結論にたどり着くのでした。(^^;
HEAD で純粋なサーバーレスポンスを計測すると結構軽いのですよね。
# 管理人さんが以前どこかに書いていましたが、ディスク I/O の負荷が最大の
問題なそうな。
■ このスレッドは過去ログ倉庫に格納されています