★負荷軽減対策委員会(Perl、PHP)★
サーバ上にPerlやPHPを置く場合、何よりも重視しなければ
ならないのはサーバへの「負荷」。
負荷の高いCGIの使用は削除対象となるのが目に見えてます。
負荷を軽減させるにはどうすればいいか?
どういう書き方をすればいいか?
そんな委員会を開設しました。 >>341
追記の場合、元のファイルの大きさはほぼ影響しない。
Cをやっている人間ならわかる(はず)だが、
追記と言うのは、ハードディスク上のファイルの終端を探し出して、
そこから新たなデータを埋めて行き、最後にファイルの大きさを示す数値を変更する作業だ。
従って、ファイルの終端を探し出す作業だけが、ベンチマークに影響する。
>>343
メモリの占有率を調べたいなら、そういうソフト入れてベンチマーク取ればわかる。
そして結果を発表すると皆から感謝される。
むしろ、その式は人間が見やすいかどうかを考慮した方がいいと思う。 下記の中で最も負荷が少ないのはどれでしょうか?
1.printを使い一行ずつ出力
2.ヒアドキュメントで出力
3.別ファイルを作り読み取らせて出力
3は後々便利そうだけど、負荷が気になる…。 >>346
負荷が少ないって、どっちの?
「省メモリ」? それとも「CPU占有の少なさ」? >>346
>3.別ファイルを作り読み取らせて出力
>3は後々便利そうだけど、負荷が気になる…。
じゃあ外部ライブラリとかあまり使わない方がいいよ。CPANもね。
>>346
1.出力処理が遅い。
2.出力処理は早い。
3.良識ある人間のやること。
一般に、メモリ占有量の低いものの方がウェブには向いているよ。
>>350
そうか?次々とくる要求に迅速に対応するために処理速度を優先しない? webプログラムは、サーバへの負荷も気をつけないといけないと思うけど、
それよりも、トラフィックを一番に考えてる俺は間違ってますか?
そんな細かい事ぐらいでサーバーから言われる事はまず無いので
私も処理速度を優先させるべきだと思うねぇ。
というか、気にするほど大して変わらない。
基地外なほど膨大なデータを扱うならまだしも。 想定同時アクセス1000くらいの小さな案件で、
鯖を用意してやるなら、保守性を一番においても問題ないと思う。 >>355
>想定同時アクセス1000
これって小さいの? 秒間同時アクセス数1000ってことだよね? 共有メモリを活用する、繰り返し使用する正規表現はlexで、
大きなプロセスは常駐させてローカルソケットでCGIと通信してCGIは小さく作る、
データベースは下手に使わない、巧く使える場合にだけ使用する。 >>354
サーバーがつんでるメモリーの量によってどっち優先かは変わると思われ。
メモリー使い切ったらswapのオーバーヘッドがかかってかえって遅くなるし。
まあ、最近のサーバーはメモリーを湯水のように持っているからそんなこと考える必要ないのかな? Perl5からPerlでもコンパイルした状態で設置できるようになったと読んだんですがどうすればできますか?
>>359
perlccを使う。
使ってどの程度早くなるかは知らんけれどね。
>>358
共有鯖ならいくらメモリ積んでいようと割り当てられるのは
微々たるもの >>360
散々言われてていることだが、perlccではモジュールはろくすっぽ使えないので注意。 >>360
早速やってみたところかなり速くなりました。
でもサイズが2kちょいから800kほどに... >>363
perlcc使ったことあるけど、2kじゃなくて2MBになったよ mod_perlだと数倍早くなるのに
perlcc だと1割くらいじゃない? ダブルクオートを極力使わないだけで結構速くなるらしい。
理由は説明しなくてもわかるよね? >>368
'"'でくくると中に'$'が入っているかを検査してるから? >>371
Yes she does!
PHP のメーリングリストなんかでも、
速度を少しでも稼ぎたいときの小技として紹介されることがあるね。 すべてのルーチンを一つのファイルにまとめてしまうのより、
ひとつひとつルーチン毎にファイルを分けて、
一度に呼び出す方が負荷が大きいですか?
>373
漏れもそれ思うんだが、ファイルをまとめようが分割しようが、
結局たいした大きさじゃないので、どっちもオンメモリってことない? 使わないコードを解釈させない為に分割するんであって、
分割しても常に全部使うのなら、まとめた方がシステムコールが
減っていいと思う。
Perl だったら CGI.pm でやってる遅延読込が参考になるかと。
あれはあれでメモリ食いそうだけど。 >>375
それじゃ、useでモジュール呼び出すより、
requireで、必要な所で呼び出す方が良いって事ですね。
>>376
別に必要になったところでuseすればいいんでないかい?
そうそう、SelfLoaderかまして起動時には一部しか読み込まれないように工夫しないといかんね。
requireはそこに来た時点で読み込まれる。
function hoge() {
require('hoge.php');
}
hoge(); らなければ読まない。
Perlも同じく。 コメントを山ほど書いたら負荷になります?
スクリプト自体軽くした方がいいんでしょうか。 >>382
富士山ほどのコメントを書いたら負荷になります。 >>382
わかるほどの差は出ないからちゃんと書いといたほうがいいよ >>386
体感できるほどの差ではない、つまり実質0 正直言って、コメントなんか処理速度に関係なんかない。
そりゃ、数百Mとかのコメントとか入れてたら、
メモリへロードするのが遅くなるだろうが、
処理速度そのものは、何の影響もない。
え????
コンパイル時に無視されて、コンパイル結果もキャッシュされる
わけなんだから、全く影響しないんじゃ? >>394
コンパイル結果に反映されないのは当たり前
コンパイル時に無視するためには最低限の判定が必要
要はコメントかどうか判定するフラグが少ないに越したことがないのか
という話でしょ CgiPerl , CgiPHP , mod_php のうち速度が一番なのはmod_phpなのは知ってるけど
負荷が掛からないのはどれ? >>396
その中に、なぜmod_perlがないんだ? printで一行づつ出力するか、
変数にデータを入れて、printで一気に出力するかどちらが負荷少ない?
それともヒアドキュメント使うか。
どれよ? >>398
そうそう、オレも知りたい。結構悩むんだよなー。みんな
その辺の使い分けはどうしてるの?
printよりechoのが速いってのは聞いた事あるけどね。 そういえばPerlにCのfflushのような関数はないのかな?
$|=1;print "";$|=0;とやるしかない? >>398
変数作って一気に出力する。
エンコード自由に変換して掃き出せるようなものの場合はどうしてもこうなる。
ヒアドキュメントは
$aya=<<EOL;
あやや
あひゃひゃ
EOL
で変数ぶち込めるし。 echo "
うほっ
いい男!
";
これでいいだろ >>399
mod_phpも同じだ。
>>401
速度は、
mod_perl > mod_php > CGI Perl > CGI php
の順。ちゃんと実験したサイト行って、見て来い。
>>408
>mod_phpも同じだ。
PHP可を謳っている鯖屋はmod_php可という意味で、CGI可(※)を謳っている鯖屋は、
CGI/Perl可という意味で謳っていると思うのだがどうだろうか?
CGI可に比べてPHP可の鯖屋が少ないのは事実だが、mod_Perlを使える
鯖屋を見た事がないのは、漏れの調べ方が甘いからなのか・・・
※)一般的にCGI=Perlという認識があるのでこのような書き方をあえてしたが・・・
つまり何が言いたいかと言うと、mod_php使える鯖がそんなに非一般的では
ないんではないかという事だ。 mod_php っていう言い方、あんまきかないんだけど、
cgi版じゃない普通(というか一般的というか)のphpってこと? >>409
適当な拡張子をApache::Registry上で
動くようにする事自体はむずかしくないんだけど
ユーザーのモジュールの名前空間に制限がかけれないので
userAが
use lib (/home/userA/lib/);
use myPackage;
としる状態で
userBが
use lib (/home/userB/lib/);
use myPackage;
とかしてくれちゃうと、動作がめちゃくちゃになってしまうので
ユーザーにmod_perlな環境を提供できません(´Д`;)
>>410
mod_phpでない場合(サーバー組み込みで無い場合)
「php対応(ただしコマンドライン版)」という表記をみかけます
>>411
レン鯖(共有鯖)ではmod_perlを提供できないって事?
って事は一般的な環境ではPHP>perlつー事? でもな、Perlには、FastCGIとかもあるからな。
>ちゃんと実験したサイト行って、見て来い。
ああいう非現実的な試行環境に統一して対照されても参考にできないよね、、
まだmsがやったベンチ結果のほうがdqnぽくない
PHP5のケース別ベンチやってくれんかな
個人では実験環境が作れないしzendの情報だけでは激しく不安だし、、
話は変わって、itboostのtips「効率的な処理」に、phpのループ構造は遅いから、
コールバック関数を繰り返し呼び出すとphpではなくcレベルでループが走ってくれるて
いいよってネタがあるけど、これはどうなん?
(あれはcountを一度にすれば大差ないような気もしつつ、、。
個人で実行速度を計測するといえば、ループ処理のことだと言ってもいいかと
おもうんだけど、これってphp特有の問題? >>412
ハンドラ好きにさせるのはもってのほかなので
Apache::RegistryかApache::PerlRunを提供するしかないと
おもうのですが、前述の問題があり、自分の知識内では
不可能と判断しています。
(他に良い方法がないか探してるのですが...)
>>414
FastCGIも、共有サーバだとデーモンプロセス上がりまくりで
現実的では無いような気がしますが^^;
>>ちゃんと実験したサイト行って、見て来い。
>ああいう非現実的な試行環境に統一して対照されても参考にできないよね、、
どこのサイトを見てるんですか?
mod_perlとmod_phpの比較は、ここな。
http://www.linc.or.jp/~takaaki/Family/takaaki/Labo/dynamic_page.shtml
>417
そのへんはコミュニケーションギャップを楽しむところだと思ったり。
__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄ ageんでも保守はできるでしょ
?>
<html><head><title><?=$title=></title></head>
<?php
と
echo << end
<html><head><title>$title</title></head>
end;
はどっちが軽いんだろうね・・・ >>428
私もそんな気がして、なるべく上の方使うようにしてる
でも変数が多いところとかは下のやつ使ってる PHPに、テキスト中に変数があるかどうか判断させる後者よりも、
明示的にする前者がやっぱ速いかな?特に変数が多いほど。
でも、PHPモードに入ったり抜けたりする負荷(と言えるかな?)を考えると前者のような気もする… echo '
<html><head><title>'.$title.'</title></head>
';
これでいいべ >>431
長い場合、echoを大量に書くわけにもいかんでしょ
HTMLのフッタ部分は定型に近いから?><?phpを使ってるんだけど
さほど変わらないのかなぁ・・・ >431-432
http://www.php.net/manual/ja/language.basic-syntax.php
にもあるとーり結局内部的には echo で処理されてるから
あとは可読性の問題じゃないかねぇ。 ∧_∧ ∧_∧
ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。
=〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
= ◎――――――◎ 山崎渉&ぼるじょあ mod_perlで動かすと、速いときはバカみたいに速いが、
遅いときはイライラするぐらい遅い。
普通こんなにバラツキがあるものなのですか? >>436
新しいhttpdの子プロセス上がった時とかキャッシュがないからでは?
重そうなモジュールは起動時に読み込むようにするとかして
コンパイル時間短くしたら?
speedyCGIで負荷が高くなると、InternalServerErrorが出るのですけど、
私の書き方が間違っているだけなんですかね? >438
mod_perl1.2使ってたとき、モジュールのキャッシュ無視して、別空間にロードされる場合も。
最近のバージョンで改善されているかどうかは不明ですが。
>>440
モジュールの更新日が変わってるとか%INC消してるとかでなく?
どうやってその現象確認しました?
>>441
初回にロードした時間を記録するクラス作って、何度かリロードして確かめた記憶が。
他にも、子プロセス関係で何かしたと思ったけど、忘れた。
%INC消さなくても、ロードされる時はされてましたよ。
ライブラリモジュールに限らず、同一ファイル、同一パッケージ名の空間も
複数のキャッシュが存在してしまうこともしばしば。
それ知って以来、mod_perlは一切使ってませんが。
で、最近のバージョンはどうなんでしょう? >>442
webDBで、mod_perlを導入したが、遅い。
まだSpeedyCGIの方がパフォーマンスが良い。
ただ、>>439 の言う通り負荷が高くなると不安定なんだよなぁ。
なんか回避方があったら、教えて欲しいよ。