前回の続きです。
アプリでの調査方法では、遅い場所(リクエスト)を探すということが重要です。
ソースを見ていても、答えを知っていれば簡単に見つかるのですが、
答えを知らないで調査するためには、今動いている本番環境で、実際に”遅い”場所を探せばいいのです。

よく、遅い環境にそのような仕掛けを入れると、より遅くなるのではないか?
といってやらない人がいますが、あまり意味がありません。

0.5秒かかるページを0.1秒にするための調査で、0.01秒程度のコストなど誤差の範囲でしょう。
性能を極限まで高めようとしたときには有効ですが、極限まで高めようとするためには、
結局、どこが極限なのかを常に把握する必要があるので、そのようなコストは必要枠だと思ってください。
また、常にサービスを監視するためにも必要なのです。

さて、「遅い」を調べる場所は2つあります。

1)DBのクエリーがどの程度時間がかかっているか?
2)WEBのアクセスにどの程度時間がかかっているか?

の2つでまず問題ありません。
DBは問題ないのに、WEBのアクセスが原因となっているケースはほぼまれです。
これは、理屈ではないのですが、私の経験上、DBで問題が発生しないにもかかわらず、
WEBに問題が発生するようなケースだと、担当しているエンジニアもそこそこの人ですから・・・

1)DBのクエリーがどの程度時間がかかっているか?

MySQLや最近のPostgreSQLなら指定した時間以上かかっているSQLがあったら自動的にログに出力してくれる機能があります。
これを使えば簡単に見つけることができます。

ただし、「このようなログ機能がない!」という方もいます。
または、DBの設定は変えられない。プログラムで何とかしなければならない。

この場合、単純にSELECTを投げる前と後で時間をとって、それで出力すればいいだけです。
今では、データベースへの検索処理もライブラリ化されてしまっている場合がほとんどなので、
そこに処理を入れてしまえばいいという訳です。

これから、設計するという場合にはもちろん、このような処理を入れることができるようにしておくことは、
DBに依存しない為にも必要という事になってきます。

さらに私は、muninを使っておそい(1秒以上)かかったSQLがどの時間帯に多いかなども調べるようにしています。
このあたりも、みたいポイントとしてリソース監視に追加ができるようであれば、追加した方がいいと思います。

次回は1)WEBの遅い場所、つまり、プログラムについて調べていきます。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2010年10月
« 9月   11月 »
 123
45678910
11121314151617
18192021222324
25262728293031

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ