★負荷軽減対策委員会(Perl、PHP)★
サーバ上にPerlやPHPを置く場合、何よりも重視しなければ
ならないのはサーバへの「負荷」。
負荷の高いCGIの使用は削除対象となるのが目に見えてます。
負荷を軽減させるにはどうすればいいか?
どういう書き方をすればいいか?
そんな委員会を開設しました。 閲覧時にクッキー使ってなにがしたいの?
投稿時ならともかく。 お!早い。
切替ならそれぞれリンクを用意するだけで済むのでは?
閲覧時のクッキーってストーキング用途しか思いつかない。 >>674
それだけしか思いつかないおまいの脳に乾杯 >>664-667あたり
2chで化けるのはbbs.cgiで発行してJavaScriptで取得してるからじゃ? つーか無理にHTML表示なんかせんでもいいよ。
動的にやればインタラクション的にも手軽になんでも出来るし。 掲示板の1ページ目だけだけど
HTMLにすんのとしないのとじゃけっこう差出るの? htmlファイルに書き出すかどうかは、そのサイトへの訪問者の利用状況によって異なる
一概に○○なら△△とはいえない。
まあ、統計的に、そのページが更新されるまでに10回以上アクセスされるとわかれば、
一般的にはhtml化した方がいいだろうな。
式にすれば
html化するコスト << html化しない場合のCGI起動コスト * not modify間での平均アクセス数
の場合は、html化のメリットが大きい まあHTMLよりCGIの方が負担少ないなんてことはないな まあHTMLにしないで負荷を軽減する方法を模索していくのもいいんでない? むしろHTML化できないからプログラムの負荷を下げる必要があるんじゃね?
本当に負荷を下げたいならCGIなんか使わずサイト丸ごと圧縮しておくのが一番だろうし。
俺はCGIを作る側だけど実は↑これが一番好き。 しかしコスト(時間や手間込み)単位での効果ならやはり静的HTML生成がベストチョイスなのも事実だし。
まあ両面作戦だね。 1, Requests per second: 2.67 [#/sec] (mean) perl/cgi
2, Requests per second: 17.53 [#/sec] (mean) mod_perl (1と全く同じソース)
3, Requests per second: 60.22 [#/sec] (mean) html (1,2のプログラムで出力された物をhtmlで保存した物)
DBIやarchive等、結構重いモジュールを読み込んでDBにアクセスして表示するプログラム。mod_perlのDBアクセスは永続化している。
処理内容によって一概にいえないけど1つのパターンとして参考までに。
静的htmlだとカウンターだのダイレクトに表示出来ないしクッキーも文字化け(IEではunicode,xxxだとURLencodeだの)
等の問題が発生してめんどくさい。クライアント依存の処理はやはり気持ち悪い。 >>687
これって数字高い方がいいってことなの?
ベンチマークに無知でスマソ
確かに文字化けるんだよな・・・
ユーザにHTMLとCGIモードを選ばせるようにしたらいいかも 書き込みのときjavascriptでクッキー発行すれば化けんよ。 「>>1」
このアンカー、2chではタグをアクセスごとにつけてるんだっけ? >>690
んだよ、ほれ。
http://pc5.2ch.net/php/dat/1034645635.dat
サニタイジングもregist時にやってるな。
2chは書き込みも多いが、それ以上に読み込みが凄まじいからな。 質問なんですが、
リンクトレードproやThe Roomのランキングリンクのようなエロサイトによくあるランキングを
PHPで作ってみました。ユーザーごとに情報を1行CSVに保存させて、それがカウントファイルも兼ねてます。
表示部分は静的です。
出来上がったところで、上司に負荷かかりそうだからDBにしてよと言われ、MySQLで作り直してみたところ、
現在ユニーク1万/日くらいのサイトであっというまにMySQL接続数多杉エラーが出ました。
サーバ管理者にMySQLの接続数多すぎと出ましたと言ったところ、
設定変えることもできるけど、トラフィック多いサイト目指すならPostgreSQLにしたほうが良いといわれました。
今とりあえず素直にPostgreをサイト見ながらソース書き直してますが、
一体どの方法がベストなんでしょうか。
ちなみにPHPは趣味レベル、DBの経験は今年からなのでソースに問題があるのかもしれません・・ >>693
postgresにすれば良いってわけじゃないような。
ユニーク1万/日ぐらいだと、squidでリバースプロクシを導入してみるとかは? >>694
今後増える予定です。目標が10万PV/日くらいです。 >>695
同時接続数を増やせないなら、1接続あたりの接続時間の短縮をやらんといけない訳で。
もうクエリを発行しないと分かった時点でコネクション切断とか、
そのレベルの最適化はやってるよね?
初心者らしいから言ってみると、WHERE句、LIMIT, OFFSETで取得数を限定して、
DBから取得したけど使わず捨てているデータを削りこむとかやってみそ。 >>696
やってるつもりなんですが、、
inのカウント取得ファイルのソースをコピーしてみます。
http・・・xxx.php?usrid=$usridで叩いて、DB開き。
$tabledata = mysql_query("SELECT * FROM usr_table",$db);
//配列に入れ
while($row = mysql_fetch_array($tabledata))
{$usr_array[$row[usrid]] = $row;}
//t1フィールドに直前IP記録&カウント
if($rmhost != $usr_array[$usrid][t1]){
$incountup = mysql_query("UPDATE usr_table set incount = ceiling(incount + 1) where usrid = \"$usrid\"");
$ipupdate = mysql_query("UPDATE usr_table set t1 = \"$rmhost\" where usrid = \"$usrid\"");
}
mysql_free_result($tabledata);
mysql_close($db);
if( !$db ) {
print "接続できません。<br>\n";
exit;
}
header("location:{$homeurl}");
これだけです。これで動いたんですが、やっぱり記述おかしかったりしますかね、、? まさか mysql_pconnect とか使ってないよね? >>693
ランクカウント以外の部分(順位の表示とかカテゴリ参加数の表示とか)はどう処理してる?
もしリアルタイムでやってるなら、静的なHTMLで処理するとかcronで処理させるとかすると、
劇的にコネクト数は減るよ。
ユニーク1万にも耐えられないならDB使う意味ないし、Postgresにすりゃいいってもんでもないと思ふ。
やはり、設計段階からの見直しが必要かと。。
毎秒何回ぐらいqueryの発行あるか分かるなら書いてみて。 mysql_pconnect思いっきりつかってますが、、それって駄目なんですか?
>>699
順位他の処理は、3600秒ごとに静的に書き出してテキストファイルをrequireしてます。
cronではなく、テキストファイルにタイムスタンプ書き出してアクセスごとにチェック、前の書き出しから+3600秒以上経っていたらランキング再書き出し、という感じです。
>ユニーク1万にも耐えられないならDB使う意味ないし、Postgresにすりゃいいってもんでもないと思ふ。
ですよね。。
毎秒何回query発行あるか、どこで見れば良いんでしょう。。
とりあえず今はサイト止まってしまうので旧テキストファイル版に戻してしまいました。 >>700
やはりそれぢゃったか
mysql_pconnect して DB に接続すると
mysql_close しても
スクリプトが実行を終了しても
それどころかクライアントがブラウザを閉じた後も
DB接続が切断されずに残り続けるんぢゃよ
つまり今の状態だと mysql_close が全く効いておらん
これは接続をプールして再接続の負荷を減らすためのGJな機能なんぢゃが
DB接続数上限が逼迫している状態では逆に足を引っ張ってしまう両刃の剣
素人にはお薦めできないとまでは言わないが、注意して使わんといかんのぢゃ
mysql の最大接続数を apache の MaxClients より大きく設定する、とかぢゃな
とりあえず mysql_pconnect を myqsl_connect に変更すれば
mysql_close で接続が切断されるようになるので
かなり状況が改善するんぢゃないかのう うわー、、そうだったんですか。
きっとそれっぽいですね。
大変勉強になります。ありがとうございました。とりあえずそれを試してみます。 >>697
なんてか、削り込み以前にDBMSの本をちゃんと読もうよ。。
header("location:{$homeurl}");
と、リダイレクト先URLしか要らないのに、
$tabledata = mysql_query("SELECT * FROM usr_table",$db);
ここで全テーブルデータをぶっこ抜いているのがそもそもの間違い。
ここは
$tabledata = mysql_query("SELECT * FROM usr_table WHERE usrid = \"$usrid\" ",$db);
と必要な行以外は抜いてこないように直すべき。 全テーブルぶっこ抜きの方法は、いわゆる「MySQLでかんたん掲示板」系の
入門書から取ってきたんだと思うけど、このやり方、小さな個人サイトなら
またしも10万PV/日のサイトに使える方法じゃない。
という訳で入門書以外のDBMS専門書を読むことを勧める。 perl のDBMモジュールでも
データーベースオープン
全データーを配列にコピー
データーベースクローズ
その後配列に対して処理色々なんてことをやってるスクリプトを見かけるが
全部読み込まなきゃいけない処理なら普通のファイルに保存したほうが軽くて速くないか?
>>706
早いかもしれないけど影響がでるほどの量だとすれば、
データの書き込み(更新)する必要がある場合dbでやる方が安全だと思う。 >>707
いや、だから、あのさ(w
db使うなら丸ごと読み込んだりしないだろう?普通 全ぶっこ抜きじゃトランザクション隔離のかけらも無いよなぁ 大前提として、どれくらいの規模(データと一日あたりのhit数)になったときに
プレーンテキストからDBに移行するべきなのかという目安を考えるべきだと思う。 サーバスペックやスクリプトの作りにもよるからなあ
とりあえず思いつくのは
・アクセス頻度と平均処理時間から待ち行列を計算して「ヤバ」と判断したとき
・top の load average が 1 を超えたとき
・HDDのスワップ音が聞こえるとき
・体感的に「重い」と感じたとき 表示用HTMLファイルとか作成しちゃうなら、場合によっては
小規模でもデータはDBで管理した方が良いね。 そうだな、俺もDBが動いてる環境なら規模によらず常にDBを使う DB使った方がコストが安くすむ…場合もあるからDB使っちゃうな。
こんな俺はきっと駄目なPGだ orz httpd.conf 最適化とかリバースプロキシとかの話はここではしてないの? >>721
それはWebProgを走らせる「環境」の話だから。
ここは共有鯖で使うCGIの負荷を以下に下げるかの話するスレ(機能してないけど) httpd.confみたいに説明書と設定ファイルが同じになってると萎える
コメント行削ったら半分以下になった すいません、ちょっと負荷の意味が違うかもしれない質問なのですが
CGIやPHPで大きなファイルなどのダウンロード速度の制限などを行えるのでしょうか。
検索してみても出てこなかったので
やはりサーバーの方で直接設定しないと出来ないものなのでしょうか。 普通はmod bandwidthとか使ってやると思うけど・・ >>724
スクリプトでファイルを読んで、pushするなら出来ないことも無い。
でも回線負荷は下がるかもしれんが、サーバの負荷軽減にはならんでしょ。
普通は>>725の通り。スクリプトでファイルを送り出すなんてしない(高負荷)。
となると,DBにファイル放り込むのはよくないのかな 教えていただき、ありがとうございました。
やはりサーバー側で直接行う方がスマートで負荷低減になるのですね。
当方サーバー側をTelnet出来ない専用サーバーをレンタルしており
スクリプトでどうにかならないか考えておりました。
SQLite機能がついており、ファイル制限が出来るらしいのですが
DBもやめた方がよいとのことで、
ありがとうございました。 >>727
管理上の必要があれば、DBに放り込むこと自体が悪いわけではない。 >>728
専用鯖なら負荷かかってもいいんじゃないの >>728
専用サーバなのにTelnetできないのかww ちょいと具体的な話でなくてもうしわけないんですがとあるWEBアプリケーション(phpからpostgresを使ってるらしい)について相談をうけまして
ちょっと覗かせてもらったらapacheのプロセスがひとつ毎に10MBほどもメモリーを消費しちゃってるんで、一瞬、え?っと思ったんですが
当方phpもpostgresもあんまり詳しくありませんのでもしかしたらこの構成だと普通の状況なのかな?とも思いまして質問させていただきました
phpはapache2.のモジュールとして組み込んで有ります。
それくらいふつうだろとか、直感的になんかあやしいとか、プログラムがタコだとそうなるとか、感想をお願いします
>>734
要約するとapacheのモジュールとして組み込まれたphpからpostgresqlを使ったらメモリーを10MBガメるのは普通ですか?
ってことだな
ただ単にApacheに色々組み込みすぎて肥大化してるんじゃない?
>>736 thx
ただのリクエストで、どれだけ消費するか見てみないと、なんともいえないね。 >>733
>apacheのプロセスがひとつ毎に10MBほどもメモリーを消費しちゃってるんで
普通。 正しくは
>phpはapache2.のモジュールとして組み込んで有ります
のような状況の場合、普通。
(PHPのエクステンションを極力動的に組み込めば減るけど) PHPってメモリー食いなんですね
もしかしてCGIから動かしたほうがいい?
>>741
10メガ位でけちけちすんなよ
別プロセスで立ち上げると負荷かかって遅くなるし >>741
その代わりPHPを使うリクエストがくる度にロードすることになるから
今度はCPU負荷が高くなるよ。まあサイトの特性で考えれ。
共有サーバなんかはセキュリティを高めるにはCGIで動かすしかないしな。
(例えリクエストの度にロードされてレスポンスが悪くなるデメリットがあるとしても) >>743
>共有サーバなんかはセキュリティを高めるにはCGIで動かすしかないしな。
何故? データの無駄な二重化が無いから負荷は軽減すると考えてもいいんじゃ?
間違ってたらスマソ データがコピーされるのは,値が変更されるときでは?
$a = $b ってしてもその瞬間にはコピーされない. らしいね。
だから、PHPでは「パフォーマンス重視の参照渡し」は
ほとんど無意味ってことかな。 C ならともかく,スクリプト書きながらそういうレベルのパフォーマンス向上を考えること自体間違いな気もするね.
むしろインタプリタだから「少しでも速度向上」を気にするのでは? >>741
eAcceleratorなんか使ったら相当違わない? >>751
要するに PHP を選択してる時点で既にパフォーマンスよりも開発効率を取ってる,ってこと.
速度上げたいなら重い処理だけ C/C++ 使うとか,あるいはハードウェアで解決するとかしたほうがいいんじゃないかな.
アルゴリズムの最適化はもちろんするけど. アクセラレータつかったりFCGI化するだけで天と地ほど違うぞ
インタプリタだからこそ工夫するというのはその通りだけど、
ざっくり体感に跳ね返ってくるレベルで考えたほうがいいと思う >>733
たかだか10Mだろ?
そこメモリ何Mのマシン使ってんのよ?
32Mとか?w
このスレッドで聞いていいかな・・・?
DBサーバとフロントサーバを分ける場合、
両者はやはり同じLAN内に設置するのが基本ですか?
離れたところに置くと、レスポンスはけっこう遅くなります?
>>758
物理的な距離とレスポンスは関係ない。
LANであろうが回線が遅ければ遅い。
WANであっても回線が速ければ速い。 マルチだけど答えておくか。
セキュリティを重視して分けておけ。 どもです。
同じLAN内に設置すべき、っていうわけでもないんですね。
でも普通はLAN内の方が回線は速そうですね。 >>761
何かLANとドメイン(≠インターネットドメイン)を
一緒くたにしてるように思えるけど。 インターネットを介さないという意味なら、プライベートIPアドレスで構成されたLANの中にウェブサーバとDBサーバを置くのが普通。 ウチはRFC1149準拠。夜間の速度が出ないのが悩み >>757
たかだか、というけど、メモリ上限のあるVPSとか借りてると結構辛いよ?