F5対策 sql発行ページにて

質問

turbolinux server10
php4 mysql5.0.18
にて
コミュニティーサイトを構築しています

sqlを発行しているページをリロード（F5長押し）すると
CPU使用率が跳ね上がります
質問内容は
「sql発行ページにてF5リロードにも絶える方法は？」です
よろしくお願いします

cpu使用率というのはTOPコマンドで表示させながら
F5長押しすると、cpu(s)の左端「us」部分の数値が100%になります
user部分には「apache」が並びます

出来るだけ単純にして
テストもしました

test.phpを用意
このphpは
１．DB接続
２．あるtblのカウントを取得（15,000件）
３．取得結果を表示
４．DB切断

このtest.phpをリロードしても結果は同じです

今の設定では
リロードすると
１．apacheは表示させようとする
２．mysqlがsql発行
３．まだsql結果が返ってこないのに、apacheは表示させようとする
　　・
　　・
　　・
と待ち行列が発生していると思っています

さて、このF5リロードしても大丈夫なWEBシステムに修正するには

１．SQLが重いから待っているだけ！これで問題なし
　　⇒sqlを見直して軽くすることに勤めろ！

２．○○の設定で回避できるよ！

３．マシン性能が云々・・・

のどれでしょうか？

私は2番の答えを希望しています
理由：１は限界です・・・多少のチューニングは可能ですが
　　　もう無理かも
　　　３は予算がありません・・・ただ、マシン性能という問題では
　　　ない気がします（P4-3.0 M-1G 線は光です）

以上、説明の足りない部分があると思いますが
よろしくお願いします

回答No.2

noname#45409

私が個人的に運用するサイトと比較してみました。

トップページで最も重いクエリが0.07秒程度だったので、クエリ１つが0.01秒ならばそんなに遅くないかな・・・と思ったのですが、２回目に実行したら0.0001 秒・・・ということで、連打されてもノープロブレムなようです。0.01秒というのが、何度も実行した後での事ですと、私のサイトと比べると遅いようです。

というわけで、my.cnf周りでも解決できそうです。
私のサイトですと、アプリケーション特性を考慮し、下記のパラメータをチューニングしています。

delayed_queue_size=***M
max_connection=***
key_buffer=***M
table_cache=***
sort_buffer_size=***M
join_buffer_size=***M
read_buffer_size=***M
read_rnd_buffer_size=***M
myisam_sort_buffer_size=***M
query_cache_size=***M
tmp_table_size=***M
thread_cache=***
値については***で潰させて頂きました。

これを全部設定するのはやり過ぎかもしれないので・・・、table_cacheやkey_bufferあたりを中心にやってみるといいです。参考URLはオフィシャルのマニュアル（日本語）です。

ところで、まさか第二段ですが、トランザクション等を使わないテーブル（マスタ等）はMyISAMですよね・・・？

参考URL：

http://dev.mysql.com/doc/refman/4.1/ja/server-parameters.html

お礼

返事か遅れて申し訳ございません

my.cnfより
key_buffer=64M　（元16M）
table_cache=256　（元64）
sort_buffer_size=4M　（元512k）
read_buffer_size=1M　（元128k）
に設定しました

初期値より値を上げた変更となります

ただ、目に見えて改善はされません

ううん・・・さてどうしようかな・・・

現象をもう一度
index.phpをクライアントから表示して
F5を１０秒押し続ける
⇒サーバー側でTOPを見ていると
　cpuは80%以上となりtasksは70から200となります
　下方の表にはuser [mysql]　command[mysqld]が１０
　user [apache]　command[httpd]が５程並びます
　1分ほどすれば、cpuやtaskesは元に落ち着きます・・・

やはり、こんなシステムおかしいですよね・・・

補足

全てmyisamです
とにかくスピードを出したかったので・・・

my.cnfについて勉強及び設定がんばってみます
結果は後日報告させていただきます

回答No.1

noname#45409

一般論ですと、どれくらい派手にF5を押したのかはしりませんが、それなりのビジターが居れば、それなりにF5を押したのと同じ状況になります。
アプリケーションのチューニングを業務で請け負う事も多々ありますが、ソースコード改修＆DB再設計で直せる、つまりアプリケーションで直す幅が一番大きいのが一般的ですので、それできっちり対応すべきだと思います。あとはdbの設定関連（my.cnf）なんかも結構効果あります。

今回特有としては・・・失礼ながら、かなりショボイ、ストレステストであっさりやられているあたり、まさかdb接続でpconnect()を使っていなかったりってありますかね・・・？
ページビューがある程度以上多い場合、pconnect()でないと死にます・・・。

そうでないとすると、my.cnf周りでだいぶいけそうですが。

お礼

テスト結果の報告が遅くなり、申し訳ございません
で、結果ですが
目に見えて改善されるような事はありませんでした
ただ、マニュアルを見ると、pconnect()を使うのが正解だと思いますので修正しました

sqlを１０個発行しているページ（index）という設計が
ダメなのでしょうかね・・・
だだ、１０個でも１つ１つは0.01秒で帰ってくるのですが・・・
うーん、どうしようかな・・・

補足

ご回答、ありがとうございます

＞ページビューがある程度以上多い場合、pconnect()でないと死にます・・・。
・・・mysql_connect()を使用していましたＴＴ

mysql_pconnectに変更してテストしてみます
（うう・・・全然しらなかったTT）

ありがとうございました！！