LaravelとLumenでベンチマークやり直し

前回の「LaravelとLumenのHello Woldを試す」は実用的な計測ではないので、
もう少し通常の動的サイトに近い処理を追加して計測してみました。

テスト環境

前回の記事を参照

LaravelとLumenで以下のファイルを追加

• ルーティング設定でHomeコントローラを指定する (app/Http/routes.php)
• データベース設定を追加する (config/database.php)
• コントローラーにデータを取得する処理を追加する (app/Http/Controllers/HomeController.php)
• モデル追加する (app/Page.php)
• ビュー追加する (resources/views/home/index.php)
• ビュー上でデータをforeachで20件ほど表示する
• セッション機能はfileを使用する
• Lumenは、機能(DotEnv, Facade, Eloquent)を削る毎にHomeControllerを修正する

Lumenは機能の有無で４パターン計測

機能の切り替えは、bootstrap/app.phpを修正する

• DotEnv, Facade, Eloquentを使用する
• DotEnv, Facadeを使用する
• DotEnvを使用する
• DotEnv, Facade, Eloquentを使用しない

Lumen5.2ではなく5.1も対象している理由

Lumen5.2ではAPI Tokenの利用を前提にしているようでsession機能が削除されました。
独自にsession機能を追加すると別のものになってしまうので、できるだけLumenをLaravelに近づけるため5.1の計測をしてみました。
ちなみに、sessionを利用したい場合は、Laravelがおすすめとのこと。

結果

framework	req/sec
Laravel 5.2	692.81
Lumen 5.1 (DotEnv, Façade, Eloquent)	1,341.92
Lumen 5.1 (DotEnv, Façade)	1,523.70
Lumen 5.1 (DotEnv)	1,632.32
Lumen 5.2 (DotEnv)	1,663.94
Lumen 5.1	1,769.84

前回の結果ほど差はありませんが、1.9〜2.5倍程度Lumenの処理性能が速い結果となりました。
DotEnv, Facade, Eloquentを使っても約2倍近い性能を得ることができるので、パフォーマンス重視の方は選択肢の１つとなるのではないでしょうか。
ソースの書き方によってはLaravelに近づけることや移植もできると思うので、良い派生プロジェクトではないでしょうか。

LaravelとLumenのHello Woldを試す

バルス待機中に気になったので確認してました。
「The stunningly fast micro-framework by Laravel.」と公言しているLumenですが、
Laravelとどの程度の差があるかHello Worldで計測してみました。

テスト環境

Intel Core i7-4790K
メモリー 16GB
Ubuntu 15.10
PHP 5.6.11
nginx/1.9.3

• 特別なチューニングはしていません
• nginxとphp-fpmの設定もインストールした時のデフォルトのままです。
• LaravelとLumenはcomposerインストールした状態です
• どちらもroute.phpで文字列"Hello World!"を返すように修正しました。
• abコマンドで計測しました

結果

Laravel 5.2     928.19 req/sec
Lumen 5.2     5589.13 req/sec

予想以上に差が出てしまいました。約6倍
機能の数が違うので、検討すべきことは多いですが、LumenはAPIサーバとかに向いているかも。オーバーヘッドの少ないWAFですね。
なかなか悩ましい結果となりました。

以上、簡易的なベンチマークでした。

Laravel 5.2

ab -c 100 -n 10000 http://laravel.local/
This is ApacheBench, Version 2.3 <$Revision: 1638069 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking laravel.local (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        nginx/1.9.3
Server Hostname:        laravel.local
Server Port:            80

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      100
Time taken for tests:   10.774 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      2580000 bytes
HTML transferred:       120000 bytes
Requests per second:    928.19 [#/sec] (mean)
Time per request:       107.737 [ms] (mean)
Time per request:       1.077 [ms] (mean, across all concurrent requests)
Transfer rate:          233.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     4  107  10.0    105     130
Waiting:        4  107  10.0    105     130
Total:          5  107  10.0    105     130

Percentage of the requests served within a certain time (ms)
  50%    105
  66%    113
  75%    114
  80%    115
  90%    117
  95%    125
  98%    128
  99%    128
 100%    130 (longest request)

Lumen 5.2

ab -c 100 -n 10000 http://lumen.local/
This is ApacheBench, Version 2.3 <$Revision: 1638069 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking lumen.local (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        nginx/1.9.3
Server Hostname:        lumen.local
Server Port:            80

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      100
Time taken for tests:   1.789 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      2110000 bytes
HTML transferred:       120000 bytes
Requests per second:    5589.13 [#/sec] (mean)
Time per request:       17.892 [ms] (mean)
Time per request:       0.179 [ms] (mean, across all concurrent requests)
Transfer rate:          1151.67 [Kbytes/sec] received

Connection Times (ms)
             min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       2
Processing:     1   18   2.7     17      25
Waiting:        1   18   2.7     17      25
Total:          2   18   2.7     17      25

Percentage of the requests served within a certain time (ms)
 50%     17
 66%     18
 75%     18
 80%     19
 90%     22
 95%     24
 98%     24
 99%     24
100%     25 (longest request)

最近気になるPHPフレームワークHelloWord性能比較大会

最近気になっているPHPフレームワークのベンチマークを取得してみました。
サーバやフレームワークなどのチューニングはほとんどしていないので、
結果は、あくまで参考程度としてください。

テスト環境

仮想環境 (1CPU memory 4GB)
PHP 5.5.9 (opcache使用)
NGINX 1.4.5

確認したコマンド※

ab -n 1000 -c 20 http://localhost.local/
※外部からではなく同じサーバで実施しています。

結果

---

Phalcon 1.2.6

---

Time taken for tests: 0.523 seconds
Requests per second: 1910.87 [#/sec]

FuelPHP 1.7

---

Time taken for tests: 1.704 seconds
Requests per second: 586.90 [#/sec]

Laravel 4.1

---

Time taken for tests: 6.171 seconds
Requests per second: 162.04 [#/sec]

php artisan optimizeで最適化
Time taken for tests: 4.925 seconds
Requests per second: 203.02 [#/sec]

Ruby on Rails 4.0.3 (特別ゲスト)

---

Time taken for tests: 2.851 seconds
Requests per second: 350.73 [#/sec]

Ruby On Rails4も含めてみました。
環境はPHPとは異なり次のとおりです。

NGINX 1.4.4
Passenger4.0.37
ruby 2.1.0

感想

---

Phalconが圧倒的な処理速度で１位です。
Laravelと比較すると約11倍以上速いですね。
FuelPHPはLaravel寄りではありますが、まずまずの性能です。

artisanコマンドで最適化されたLaravelでもそれほど大幅には変化がなかった(でもLaravel比だと25%アップ)ので、速度が出ないのは、autoloadが原因ということはなさそうです。
LaravelはIoC Containerというのが得意で、コードがきれいで書きやすいのですが、
それが原因かどうかはわかりませんがパフォーマンス面では他に劣るようです。
今のところPHPでもRailsと同様にパフォーマンスと便利な機能は相反するようですね。
またPhalconが速いのはC言語で実装されたフレームワークの部分だけなのでPHP部分はそんなに変わらないのではないかと思います。
結果はPhalconが目立ちすぎてますが、実際のロジックを実装した状態ではそこまでは差がないのではないかと考えています。
また、PhalconはC言語で実装されているので運用面でトラブルの際の調査も難しくなりそうで、
仕事に使うのはZephirで実装されるバージョン2.0までは様子をみようかと思っています。
Zephirは今後どうなるか気になるところです。
LaravelがZephirで実装されたりとか・・・、今のところその動きはなさそうですが。

Railsは、言語違いますがフルスタックのフレームワークの代表例として参考になるかと思って追加しました。
LaravelとFuelPHPの中間くらいで以前より速くなってますね。
RubyのVMが進化していたり、Rails自体もチューニングが進んでいるのかも。

いずれにせよ、現実的ではないHelloWorld程度の比較なので、
あまりこの結果を鵜呑みにしないようにご注意ください。



NGINXの仮想ホスト名(server_nameディレクティブ)のメモ

NGINXで仮想ホスト名(サーバ名)を指定する方法が公式のドキュメントにコンパクトにまとまっていたのでメモ。
あまり難しいことをやらない分わかりやすいですね。

マスタリングNGINX(20,21ページ)はもう少し詳しいですが、普通の使い方なら以下の完全一致、ワイルドカード、正規表現の内容で十分かもしれません。

サーバ名

http://nginx.org/ja/docs/http/server_names.html

以下引用です。

サーバ名解決の優先順位

1. 完全一致名
2. アスタリスクで始まるワイルドカード名: *.example.org
3. アスタリスクで終わるワイルドカード名: mail.*
4. 設定ファイル内の順序での正規表現

ワイルドカード

・ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。
・サーバ名 www.*.example.org や w*.example.org は無効です。
・特別なワイルドカードの形式 .example.org は、完全一致名 example.org とワイルドカード名 *.example.org の両方にマッチさせるように利用できます。

正規表現

サーバ名は正規表現を使用して、例えば ~^www\..+\.example\.org$ や ~^w.*\.example\.org$ として指定することができます。

ワイルドカードで有効なサーバ名の指定方法

server_name *.example.org
server_name example.*
server_name ~^www\..+\.example\.org$
server_name ~^w.*\.example\.org$

無効なサーバ名の指定方法

server_name www*.example.org
server_name www.*.example.org

サーバ名未定義のリクエストを防ぐには、_のように無効なドメイン名を使います。

サーバ名未定義のリクエストの処理を防ぐ

http://nginx.org/ja/docs/http/request_processing.html#how_to_prevent_undefined_server_names

server {
    listen       80  default_server;
    server_name  _;
    return       444;
}

シンプルでわかりやすいルールですね。
仕事ではApacheを使うことが多いですが、個人的にはNGINXいいですね。

nginxでgitリポジトリの公開 - Smart HTTPを試してみた

nginxでgitリポジトリを公開してみます。
Smart HTTPというのが使えるようですが、こちらの例ではApache HTTP Serverでしたが、
特別なことは必要なさそうなので、nginxで試してみます。
80番ポートで通信できるとか、認証方法によっては鍵が必要なかったりといろいろ使い道がありそうですね。

こちらを参考にしました。

• Smart HTTP Transport


• git-http-backend(1) Manual Page


• fcgiwrap

nginx 1.2.1を使用しますが、インストール手順は省略します。
上記の記事によるとgit-http-backendを動かす必要があるので、fcgiwrapを使ってみます。

fcgiwrapインストール

• fcgiwrapインストール

yum -y install fcgi-devel.x86_64
cd /usr/loca/src
git clone git://github.com/gnosek/fcgiwrap.git
cd fcgiwrap
autoreconf -i
./configure --prefix=/usr/local/fcgiwrap
make
make install

• fcgiwrapの起動

sudo -u www /usr/local/fcgiwrap/sbin/fcgiwrap -c2 -s unix:/tmp/fcgiwrap.sock >> /var/log/fcgiwrap.log &

nginx設定

• 試しに設定したserverセクションです。

ドメイン名、パス、認証方法などは適宜変更してください。

server {
listen   80;
server_name git.example.com;

access_log /usr/local/nginx/logs/git/access_log;
error_log /usr/local/nginx/logs/git/error_log;

location / {
auth_basic            "Restricted";
auth_basic_user_file  htpasswd;

include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /usr/local/git/libexec/git-core/git-http-backend;
fastcgi_param GIT_PROJECT_ROOT /var/git;
fastcgi_param GIT_HTTP_EXPORT_ALL "";
fastcgi_param PATH_INFO $uri;

fastcgi_pass unix:/tmp/fcgiwrap.sock;
}
}

設定が完了したらnginxを再起動します。
認証が無いと誰でもアクセスできるので、なんらかの認証は設定した方がいいですね。

gitリポジトリ作成

• 空のリポジトリ作成と初期設定

git init --bare --shared=group foobar.git
cd foobar.git
cp hooks/post-update.sample hooks/post-update
git update-server-info
git config http.receivepack true

• パーミッションの設定

環境の合わせて適宜gitリポジトリのディレクトリに設定してください。

動作確認

git clone http://git.example.com/foobar.git
Cloning into 'foobar'...
Username:
Password:
warning: You appear to have cloned an empty repository.

cd foobar
touch test.txt
git add .

git commit -m 'test'
[master (root-commit) b578ac5] test
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
git push origin master

git push origin master
Username:
Password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 206 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://git.example/com/foobar.git
* [new branch]      master -> master

pushができない(receivepackが有効でない場合のエラー)

receive-packの設定が無効の場合は、pushができませんでした。
アクセスログに401やWebDAVのPROPFINDメソッドとか出てたりしたので若干混乱します。
原因は、下記のようにfcgiwrapが出力するreceive-packの設定でした。

gitコマンドのエラー
error: Cannot access URL http://git.example.com/foobar.git/, return code 22
fatal: git-http-push failed

fcgiwrapのエラー
Service not enabled: 'receive-pack'

これらの必要な設定(http.receivepack)は、git-http-backend(1) Manual Pageに書いてありますね。

httpでも一通りgitが使えることが確認できました。