それとも、DB系がボトルネックになるので、フレームワークの採用が全体に与える影響は少ないのでしょうか?
ちなみに、PHPでオーバーヘッドのベンチマークを取ったところ、インスタンス有のクラスを作った場合、ベタ書き、関数呼び出しのみ、インスタンス無しのクラスに比べて、速度が約30%低下しました。
このようなオーバーヘッドが積み重なった場合、webサービス全体のパフォーマンスが低下するのでは、と懸念し、ご質問させて頂きました。
■実例
http://japan.cnet.com/interview/story/0,2000055954,20088792,00.h...
GREE.jp は言語はPHP、フレームワークとして Ethnaを採用
「一定規模以上のwebサービス」にあたるでしょう
私の意見としては、一定規模であるからこそ
フレームワークを使わないと収拾がつかないし、
インスタンスをつかってオブジェクト指向で作らないと
大変かと思います。
-----------------------------------------------------
性能測定ですけど、支障がなければどんな条件・処理内容で
計測されたのでしょうか?
100リクエストとかアクセスが集中するような性能はどう
ですか?
あまりポイントには興味がなくて、性能測定結果に興味がある
ので、考察はしたいと思います。
開発フェーズのコストを低くする代わりに、
運用フェーズのコストを高くするものである
運用フェーズのコストとは何を表わすか?
正直作り捨てならばどのような書き方でも何とかなるでしょう。
運用中に何度も変更を経ることでシステムは成熟していきます。
この面でもフレームワークのメリットは生きてくると思います。
というよりまともな作りでないなら、改善もままならない。
確かにフレームワークのオーバーヘッドによる性能デメリットはあるでしょう。
しかし逆にフレームワークを使わなければどの程度の開発・運用コストが変わると思いますか?
3割程度の差であれば、その分サーバーの性能を上げるだけです。
また、今のままであれば半年程度の技術革新でその程度のスペックは吸収できるでしょう。
開発・運用両面での人的コストの方がはるかに高いと思います。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
「一定規模以上のwebサービス」にあたるでしょう
私の意見としては、一定規模であるからこそ
フレームワークを使わないと収拾がつかないし、
インスタンスをつかってオブジェクト指向で作らないと
大変かと思います。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
それは勿論その通りなのですが、
フレームワークはその性質上、
開発フェーズのコストを低くする代わりに、
運用フェーズのコストを高くするものである
という認識でいるのですが、
どれ程、パフォーマンスに影響を
与えるのか、というのをご質問させて
頂いたのが、今回の質問の意図でした。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
性能測定ですけど、支障がなければどんな条件・処理内容で
計測されたのでしょうか?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
これはスケールとは全く関係のないレベル
で、(1)DB接続、(2)DB情報取得、(3)DB切断
の3ステップを行う処理を、
A.ベタ書き
B.関数呼び出しのみ、
C.インスタンス有のクラス、
D.インスタンス無しのクラスで実装し、
速度を比較しました。