APCいろいろと、「stat()を呼びまくるのを眺める」の補足 (解決はできてない)
以前のエントリなのですが、バーコードリーダー萌えのkuせんせいから、そもそもstatって重いのか、と聞かれました。
そうなのですよ。確かに、statをいっぱい呼んでいることは分かるのですが、その処理が重いのかってのを知らないのです。PEARモジュールを普通に使うだけでも、statの数は軽く500を超えたりするので、「ちりも積もれば、」なんでしょうが、その「ちり」のコストがどれくらいなのか。
実際のところ、OSレベルでキャッシュかかったりもするので、自分は良くわからんのです。BSDとLinuxでも違いがあるかもしれないし。
realpathチェックを外して驚きの早さ30%アップ!な
の記事では、FreeBSDが重いよと書いているようにも読み取れます。
いろいろ実験してたのですけど、まだ、きちんとした結果を出せてないです。はい。どう実験したらよいか考えてるところであります。
いろいろ読んでみた資料を以下に書いておきます。
Building Scalable PHP Applications
OmniTIのGeorge Schlossnagle氏がZend Conferenceで発表したスライド。
この中の "10 Best Practices" の2つ目、 "Control your include trees to no more than 10 includes." (p.14)には以下のようにある。
- Including a file is expensive, even when using a compiler cache.
- Path resolution must be performed, resulting in at least one stat() and a realpath() call.
- A reasonable number of includes is fine (and promotes good code organization), but 25, 50, 100+ will impose a real performance penalty.
- I stick to 10 as my personal metric.
ってことで、
- ファイルのincludeはコストが高い。コンパイラキャッシュを利用しているときでさえ。
- パス解決は必ず実行され、これにより1回以上の stat() と 1回の realpath() が呼ばれる
ということだから、APCのキャッシュ利用前にパス解決で呼ばれてしまうということか!
おすすめの本 "Advanced PHP Programming"
Opcodeの変換の話なんてところまで書いてある書籍なんて、皆無だと思いますが、"Advanced PHP Programming" では、そんなことまで書いてます。(上のGeorge Schlossnagleの著書で、洋書です。。) 目次を見てもらうと分かるように、コーディングスタイル、OOPから始まり、デーモンの書き方、パフォーマンスチューン、ZEND Engineの仕組みからExtensionの書き方まで、えらい守備範囲です。おすすめです。
8月にsecond editionが出るようです。現在発売されているfirst editionは、2004年2月の発売ということで、PHPのVersion 5.0.0 Beta 4が出た頃 (RC1すら出てないころ)に出版されており、だからといって、内容がダメなんてことは無いのですが、現在の状況に合わせて書き直されると、ますますよくなるかなと思ってます。
- 作者: George Schlossnagle
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2020/02/19
- メディア: ペーパーバック
- クリック: 4回
- この商品を含むブログ (3件) を見る