企業が展開するアプリケーションのパフォーマンスが果たして何に影響するかエンジニア一本で過ごすと見えない部分になりがちですがアプリ/アプリケーションのレイテンシが悪いと世界大手の企業から以下のような調査も出ています。

昨今のデータドリブン・テキストドリブンで収集【する・した】、ビッグデータを扱うエンジニア・大規模サイトにとっては上記が結構ダメージデカい部分にもなります。

私が在籍する部署では主にPlatform言語(主にPHP)の開発がメインになりますが案件によってはFramework利用・自作することもあります。

多種多様のFrameworkを利用する際には、実装量の削減や開発工数の短縮につながったりするメリットがある一方で、そのプロセスでは当然利用しないファイルが読み込まれたり、無駄なインスタンスが生成されたりすることで処理速度性能がPlatformと比較するとパフォーマンスに差が生まれるデメリットがあります。

ではいったいどのくらい差があるのか。
Framework毎にどれだけ差があるのか。
各言語を元にFramework毎にbenchmark検証を確認してみます。

（参考）http://www.techempower.com

上記はJSONデータのシリアライズを行った結果です。PlatformとFrameworkには大きな差も存在しています。
それもそのはず、得手不得手を鑑みてもFrameworkにはOnLoadレイテンシによる差が現れてきます。
我々人間からしてみたら、ミリ秒・マイクロ秒の世界ではありますが
積り重なると当然パフォーマンスへ顕著に表れてきます。

Frameworkなんかメリットないじゃん！発想も理解できますが、
開発者からしてみれば予算とか・・・スケジュールとか。。。
制約も存在する中で、継続的・持続的案件別に「どう実現していくか。」その中でも
適したFrameworkの選択肢もディレクションする必要がありますね。

2015/3月段階では日本で人気なCakePHPはもう・・・という感じですね…
日本語マニュアルもありますし、cloud環境やハードウェアスペックでごまかしも聞くかもしれませんが
時代遅れになることをわかった上で利用するよりも
Frontメインではyaf、Fullとしてはhhvmとphalconがとても優秀な数値を叩き出していますので
追々ご紹介していきたいと思います。

次回はアプリケーションパフォーマンスについて記事にしていきたいと思います。

[[バックエンドパフォーマンスまとめ]]

■バックエンドパフォーマンス【PHP/Framework別】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/通信編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/require・inclode編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/DB接続編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/文字列編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/定数編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/シングル・ダブルクォーテーション編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/厳密比較関数・演算子編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/分岐構文編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/配列関数編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/ソート編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/ループ構文編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/データフォーマット編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/外部コマンド編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/検索編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/コンパイルキャッシュ編】
(記事作成中)■バックエンドパフォーマンス【PHP/処理/マルチプロセス編】