同じPHPフレームワークを選択する方法。 ベンチマーク

ソフトウェア製品を開発する場合、開発者のチームはまず、ソフトウェアシステムの構造を決定するソフトウェアプラットフォームを正しく選択するという課題に直面します。

これを行うには、「すべてがどれだけ速く機能するか」から「しかしこの機能が必要ですか？」まで、かなり多数の特性を考慮する必要があります。 そして毎回。 ブレインストーミングの瞬間に、チームはフレームワークの利便性、速度、それに実装されている一連の機能、またはフレームワークと互換性のあるモジュールを比較します。

しかし、どちらがより良く、より速く、より生産的ですか？

開発者はフレームワークを常に比較して、この問題を自分自身で明確にしています。 たとえば、Lukasz Kujawaの記事は PHPフレームワークを比較しています。 1つの「but」は2013年の記事です。 しかし時間が経ちます...したがって、私たちはフレームワークの独自の実際の比較を行うことにしました。

パフォーマンスを評価するために、 PHPフレームワークベンチマークが使用されました。 彼は比較のために多くのフレームワーク（上記のものだけでなく）を提供していますが、著者はプロジェクトの新しいバージョンをリポジトリに追加することを急いでいません。 新しいバージョンを追加する場合は難しくありません。

この記事の主な目標の1つは、PHPの新しいバージョンの生産性と効率の実用的な改善を見出すことです。 したがって、テストはPHP 5.6 / 7.0 / 7.1で実施されました

何を比較しますか？

比較のために、次のフレームワークが選択されました。

• スリム-3.0
• ci-3.0
• ルーメン-5.1
• yii-2.0
• silex-1.3
• 燃料1.8
• phpixie-3.2
• zf-2.5
• zf-3.0
• symfony-2.7
• symfony-3.0
• laravel-5.3
• laravel-5.4
• bluz（バージョン7.0.0-PHP5.6の場合、PHP7.0以降の場合はバージョン7.4）
• ze-1.0
• ファルコン-3.0

テストは条件付きで4つのタイプに分けられます。

• スループット
• 占有メモリ（メモリ）、
• ランタイム（実行時間）、
• インクルードファイル（インクルードファイル）の数。

テスト手法とテストベンチ

テストが行​​われたマシンは、次の特性があります。

Operation system: Linux Mint 17 Cinnamon 64-bit
Cinnamin Version 2.2.16
Linux Kernel: 3.13.0-24-generic
Processor: Intel Core i3-4160 CPU 3.60 Ghz X 2
Memory: 8 GB

Server version: Apache/2.4.7 (ubuntu)
Server build: Jul 15 2016
php 7.1 / php7.0 / php5.6

コマンドを入力すると、 git clone https://github.com/kenjis/php-framework-benchmark -とフレームは、私たちの車の中にすでにあります。 私たちはミントを使用しているので、あなたが設定する必要があります。

# Added net.netfilter.nf_conntrack_max = 100000 net.nf_conntrack_max = 100000 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 10

sudo sysctl -p

PHPフレームワーク - ベンチマークの構造について少し：

/ベンチマーク - （ユーティリティ、abで）1秒あたりの要求数に関する情報を収集するための責任があるのbash-スクリプト、情報の量が含まれ、多くの時間を費やした、そしてどのように多くのファイルがファイルから呼び出される「出発点。」

/ libに - 「Hello World」のページが表示された結果とチャートとテーブルの撤退後に受信した情報を処理するための責任があるファイルを含むディレクトリ。

/出力 -ログは、テスト後に追加されているディレクトリ。 テストされたファイルのそれぞれのための2つのファイルがあります。.ab.log - ユーティリティの作業の後にログはABで、.OUTPUT - （通常ハロー世界とメモリデータ、実行時には、ファイルを使用）、画面に表示された情報が含まれています。

残りのフォルダ - すでに1つのコントローラに追加された空白のフレーム、ルールによってコンパイルされたURIの循環と、文字列の「Hello World」を返します。このフレームワークを参照してください。

テストを開始するには、最初のフレームワークを設定する必要があります。 二つのアプローチを考えてみましょう。

チームbash setup.shのconfigure fremvork list.sh.ファイルに記載されているもの あなたはそれを編集することができますテストするフォルダを追加し、削除します。 それはあなたがする必要があるように設定されています。

コマンドbash setup.sh fatfree-3.5/ slim-3.0/ lumen-5.1/ silex-1.3/ 3.0 /ルーメン-5.1 /サイレックス-1.3 /あなたはコマンドにそのパラメータを設定し、任意の別のフレームワークをインストールすることができます。 いくつかのケースでは、それは便利ですが、我々は最初のアプローチを使用していました。

フレームワークの設定を行った後、我々は使用してテストした打ち上げbash benchmark.sh 。

端末の終わりでテストフレームワーク、秒あたりの要求の数、メモリの相対値、ならびに、これらのパラメータの相対値のリストを含むテーブルがありました。

表示グラフのために、我々はへの参照を使用します。http：// localhostの/ PHPフレームワーク-ベンチマーク/を 。

あなたが想像できるように、Apacheの設定を作成し、彼がフォルダフレームに見えるようにする必要がありました。 このすべては、Readmeファイルに記述されているので、問題は発生しません。

テストフレームワークの結果

各セクションは、結果の提示2つの形式からなる構造を有しています。

最初の形式は、 - これは表現の良いタイプです。 それぞれの特性図は、4が含まれています。 各チャートは、フレームワーク、プラス累積グラフの比較を示します。 これは、PHPの特定のバージョンを使用して構築されました。 したがって、PHPやフレームワークの改善の進化を追跡することが可能です。

二番目の形式は、 - テーブルの形でのテストの結果である（十分な明瞭さ、のは、真剣に話をしましょう - 私はより多くの数字を与えます！）。

生産性（スループット）

我々の状況に関しては、スループット特性は、我々のフレームワークが秒以内に処理することができることを要求数で測定されました。 数、より生産我々のアプリケーション、したがって、より高いそれは正しくプロセスは、多数のユーザーを要求することができますので。

我々は（クエリ毎秒）以下の結果を得ました：

	PHP 5.6	PHP 7.0	PHP 7.1
phalcon-3.1.2	5058.00	5130.00	7535.00
CI-3.0	2943.55	4116.31	4998.05
スリム3.0	2074.59	3143.94	3681.00
Yiiの-2.0	1256.31	2276.37	2664.61
サイレックス・-1.3	1401.92	2263.90	2576.22
ルーメン-5.1	1316.46	2384.24	2741.81
ZE-1.0	1181.14	1989.99	1741.81
phpixie-3.2	898.63	1677.15	1896.23
燃料-1.8	1044.77	1646.67	1770.13
bluz-7.3.1	- *	1774.00	1890.00
ZF-2.5	198.66	623.71	739.12
ZF-3.0	447.88	1012.57	1197.26
symfonyの-2.7	360.03	873.40	989.57
symfonyの-3.0	372.19	853.51	1022.28
laravel-5.3	258.62	346.25	625.99
laravel-5.4	219.82	413.49	600.42

* - bluz-7.3.1は、PHP 5.6をサポートしていません。

明確にするために、PHPのバージョンごとにチャート：

PHP5.6：


PHP7.0：


PHP7.1：


（フレームワークによって）全体累積チャート。

占領メモリ（最大メモリ）

（メガバイト単位）この機能は、そのタスクのパフォーマンスでフレームワークによって占められるメモリの量を担当しています。 小さなこの数、より良い私たちのために、サーバ用：

	PHP 5.6	PHP 7.0	PHP 7.1
phalcon-3.1.2	0.27	0.38	0.37
CI-3.0	0.42	0.38	0.38
スリム3.0	0.61	0.55	0.55
Yiiの-2.0	1.31	0.91	0.91
サイレックス・-1.3	0.74	0.65	0.65
ルーメン-5.1	0.80	0.63	0.63
ZE-1.0	0.79	0.56	0.56
phpixie-3.2	1.22	0.82	0.82
燃料-1.8	0.7	0.6	0.6
bluz-7.3.1	- *	0.69	0.69
ZF-2.5	3.06	1.34	1.34
ZF-3.0	2.12	1.09	1.08
symfonyの-2.7	3.11	1.41	1.42
symfonyの-3.0	2.86	1.30	1.32
laravel-5.3	2.91	2.04	2.04
laravel-5.4	3.04	1.45	1.49

* - bluz-7.3.1は、PHP 5.6をサポートしていません。

PHP 5.6：


PHP 7.0：


PHP 7.1：


（フレームワークによって）全体累積チャート。

ランタイム

リードタイム - それはタスクにシステムにかかる時間。 発行システムへのタスクの実行結果の先頭から測定しました。

私たちは、それはしばらく時間がかかりますどのくらいのメモリ、秒あたりの要求は、フレームワークを扱うことができますどのように多く考えられてきました。 今、私たちは、サーバーからの応答を得ることを期待すべきであるどのくらいのことを検討してください。 より良い私たちのために、そしてお客様のアプリケーションの神経系のために、値を下げてください。

時間はミリ秒（ms）に示されています：

	PHP 5.6	PHP 7.0	PHP 7.1
phalcon-3.1.2	1.300	1.470	1.080
CI-3.0	0.996	0818	1,007
スリム3.0	1,530	1.228	0.662
Yiiの-2.0	1478	1.410	1.639
サイレックス・-1.3	4.657	1.625	2.681
ルーメン-5.1	2.121	1.829	1.228
ZE-1.0	2.629	2.069	1.528
phpixie-3.2	9329	4.757	1,911
燃料-1.8	3.283	2,684	1.425
bluz-7.3.1	- *	1.619	1.921
ZF-2.5	22042	5.011	3.998
ZF-3.0	12680	2.506	2989
symfonyの-2.7	6.529	3.902	2.384
symfonyの-3.0	9335	3.987	2.820
laravel-5.3	19885	4.840	2.622
laravel-5.4	19561	4.758	3.940

PHP 5.6：


PHP 7.0：


PHP 7.1：


（フレームワークによって）全体累積チャート。

ファイルを含めます

多くの責任がある特徴は、フレームワークのファイル「エントリーポイント」で説明されているファイルが含まれています。 システムが検索および接続時にいくつかの時間を費やしていることは明らかです。 それは仕事をスピードアップキャッシュでの作業後の時代の枠組み、通常であるので、その結果、 ファイルより小さく、より速く 、アプリケーションの最初の起動になります。

phalcon-3.1.2	5
CI-3.0	26
スリム3.0	53
Yiiの-2.0	46
サイレックス・-1.3	63
ルーメン-5.1	37
ZE-1.0	68
phpixie-3.2	163
燃料-1.8	53
bluz-7.3.1	95
ZF-2.5	222
ZF-3.0	188
symfonyの-2.7	110
symfonyの-3.0	192
laravel-5.3	38
laravel-5.4	176

5.3とLaravel Laravel 5.4の間に含まれるファイルの数の差は奇妙に思えると協議、紛争などを生じ得ます 私たちは、状況を明確にするために早めます。 次のコマンドで、知っているように

php artisan optimize --force

Laravel 5.3でファイルcompiled.phpを生成することができ、それによって1にそれらを置くことによって、インクルードファイルの数を減らします。 しかし、そこに1がある「ではなく」：Laravel 5.4でこのファイルを生成するためのチームはもうありません。 （数えて開発者は、この機能を削除することを決めたhttps://github.com/laravel/framework/pull/17003 、そのパフォーマンスチューニングがopcacheを使用することをお勧めします）。

私は更新する必要がありますか？

バージョンの概要は以上のPHPの新しいバージョンへの移行（または初期選択）時の生産性の向上と資源の有効利用を何が起こるかを示しています。

Zend Frameworkの2.5> 200％ - PHP 5.6からPHP 7.0最小限の性能Laravel 5.3 + 33％の増加、及び最大とほぼ+ 90％の平均生産性の向上に変更する場合。

バージョン7.0から7.1への移行はとても衝撃的な、まだ約20％の性能増加の平均値を与えていません。

PHPの異なるバージョンのパフォーマンス上のすべてのデータを持ち込み、我々はここに来る「マットレス」です。

楽しい事実：Laravel 5.3 PHP 7.0が、バージョン7.1、バージョン7.0から移行中の最大の増加にPHP 5.6から移行するときのパフォーマンスに最小の増加を示し、その結果- Laravel 5.3及び5.4 PHP 7.1の性能に実質的に同じです。

メモリ消費量は、PHP 7.0にPHP 5.6からの移行は、アプリケーションが30％より少ないメモリを消費することができますように、最適化されています。

バージョン7.1へのバージョン7.0からのアップグレードはほとんどない成長を提供し、そして最後のSymfonyとLaravel、彼らはより少しを開始するため、「マイナス」に行くんで、「食べます」。

そこ実行時に見てより多くのであり、そう、ここでは、あまりにも、すべてが正常です。

• PHP 7.0にPHP 5.6から移動すると、あなたに44％の平均による加速度を与えるだろう。
• PHP 7.1にPHP 7.0から移動すると、あなたに別の14％の加速が得られます。

ご注意 ABを使用してテストする - 私たちが直面しているものを

「どのようなスリムでphpixieで» - この質問は、これらのフレームワークとの対話ユーティリティABの行動を調査するよう求めています。

スリム3.0に対して個別にテストを実行します。

ab -c 10 -t 3 http://localhost/php-framework-benchmark/slim-3.0/index.php/hello/index

Concurrency Level: 10
Time taken for tests: 5.005 seconds
Complete requests: 2
Failed requests: 0
Total transferred: 1800 bytes
HTML transferred: 330 bytes
Requests per second: 0.40 [#/sec] (mean)
Time per request: 25024.485 [ms] (mean)
Time per request: 2502.448 [ms] (mean, across all concurrent requests)
Transfer rate: 0.35 [Kbytes/sec] received

何かが間違っている - 秒あたりの要求の数、わずか0.4（！）

ab -c 10 -t 3 http://localhost/php-framework-benchmark/laravel-5.4/public/index.php/hello/index

Concurrency Level: 10
Time taken for tests: 3.004 seconds
Complete requests: 1961
Failed requests: 0
Total transferred: 1995682 bytes
HTML transferred: 66708 bytes
Requests per second: 652.86 [#/sec] (mean)
Time per request: 15.317 [ms] (mean)
Time per request: 1.532 [ms] (mean, across all concurrent requests)
Transfer rate: 648.83 [Kbytes/sec] received

これは、詳細はここで見つけることができ、キープアライブ接続していました。

「あなたは«接続：キープアライブ»との要望作るときに同じTCP接続を使用するサーバーに後続の要求を。 これは、HTTPの永続的な接続と呼ばれています。 これは、サーバー側での減少CPU負荷で助けと待ち時間/応答時間を改善します。

要求が«接続：閉じる»で作られている場合、これは、要求がなされた後、サーバーが接続を終了する必要があることを示しています。 それで、要求ごとに新しいTCP接続が確立されます。

デフォルトHTTP 1.1のクライアント/サーバ用途はキープアライブどこHTTP 1.0クライアント/サーバがキープアライブデフォルトではサポートされませんよう。」

このように、スリム試験を次のようになります。

ab -H 'Connection: close' -c 10 -t 3 http://localhost/php-framework-benchmark/slim-3.0/index.php/hello/index

Concurrency Level: 10
Time taken for tests: 3.000 seconds
Complete requests: 10709
Failed requests: 0
Total transferred: 2131091 bytes
HTML transferred: 353397 bytes
Requests per second: 3569.53 [#/sec] (mean)
Time per request: 2.801 [ms] (mean)
Time per request: 0.280 [ms] (mean, across all concurrent requests)
Transfer rate: 693.69 [Kbytes/sec] received

おわりに

予想されるようにパフォーマンスの誰もが認めるリーダー（ない開発速度）Phalconです。 最初のPHPフレームワーク - （ただし、ソースコードはPhalcon書かれているC、）の間と、実際には - - 第二位のCodeIgniterは3を取ります！

もちろん、我々はその各楽器その目的を忘れてはなりません。 あなたは、単純なアプリケーションやREST APIから別の何かを小型・軽量なフレームワークを選択して、その上に書き込みしようとしている場合、機能を拡張する際に、そして最も可能性の高い、あなたは問題が発生します。 そして、その逆 - フル機能の冗長性の、大規模なフレームワークがさえ重い負荷の下で基本的なアプリケーションのホスティングを維持するための財政的コストを伴います。

このテストは、実際に増加し、パフォーマンスを知らせるために、バージョン7.0とあなたの心の中および将来のプロジェクトに7.1の立場を強化するために/共有/ PHP言語を説得するために行われました。

内部データ構造のリファクタリング、および抽象構文木の形でコードをコンパイルする前に、追加のステップを追加する - 抽象構文木（AST）、 - 優れた性能とより効率的なメモリ割り当てにつながっています。 結果自体は約束を示しています。テストは、実際のアプリケーションで実行PHPは二倍の速PHP 5.6のように、平均で7であることを示し、および使用を50％以下からHHVM JITコンパイラのためのPHP 7強力な候補になり、クエリの処理時間、中にメモリFacebookの。

テストは完全に要求RNR7の二倍緊急処理を確認し、メモリの削減量は、使用されます。