以下の記事が目に留まりました。
Free Performance Boost : r/laravel https://www.reddit.com/r/laravel/comments/1no963s/free_performance_boost/
投稿の主張を要約すると、
PHP-FPM から Nginx Unit に切り替えたことでパフォーマンスが向上し、 アプリケーションを稼働させていたサーバー台数を約 40% 削減できた。
という体験談です。
他のコメントでも、
- 高並行・小さなリクエスト処理に強みが出やすい
- 一部のワークロードでは差が小さい可能性もある
といった補足がなされており、万能というわけではないものの、 当時は一定の効果を感じていたケースもあったようです。
Nginx Unit とは?
公式サイト:
Universal web app server — NGINX Unit
https://unit.nginx.org/
公式サイトには以下のような記載があります。
As of October 2025, NGINX Unit is archived and unmaintained.
2025 年 10 月時点でアーカイブされ、現在はメンテナンスされていないプロジェクトとなっているようです。
つまり、少なくとも現時点では積極的な採用を前提とした技術ではなく、 過去にどのような設計思想のもとで開発されていたのかを理解する対象と見るのが適切かもしれません。
Nginx Unit は、HTTP サーバとしての機能とアプリケーション実行環境を 一体化した「アプリケーションサーバ兼ランタイム」と位置付けられていたソフトウェアです。
主な特徴として、以下のような点が挙げられていました。
- HTTP サーバとして動作しつつ、アプリケーションコードを直接実行できる構成
- 静的ファイル配信、TLS 処理、ルーティング、アプリケーション実行などの統合
- 設定を RESTful JSON API 経由で動的に変更可能
- PHP / Python / Go / Node.js / Ruby など複数言語を同一インスタンス上で共存可能
- 異なるバージョンの言語ランタイムの同居
- パスやヘッダーなどに基づく柔軟なルーティング設定
また、内部的には epoll や kqueue などのイベントループを活用した 非同期処理モデルを採用しており、軽量なリクエスト処理を志向した設計が意図されていたようです。
なぜ高速化を感じる可能性があるとされていたのか
Reddit の体験談と Unit の構造を踏まえると、 以下のような要因がパフォーマンス改善に寄与すると考えられていたようです。
プロセス間通信 (IPC) の削減
一般的な Nginx + PHP-FPM 構成では、
HTTP → Nginx → PHP-FPM
という経路で処理が行われ、 Nginx と PHP-FPM 間の通信には Unix ソケットや TCP が利用されます。
この通信には、
- シリアライズ/逆シリアライズ
- 複数のシステムコール
- コンテキストスイッチ
などのオーバーヘッドが伴います。
Unit では HTTP リクエスト処理とアプリケーション実行を より近接した形で扱う構造を取ることが可能であり、 こうした通信コストを削減できる可能性があると考えられていたようです。
機能統合による構成の簡素化
従来のように、
- Web サーバ
- リバースプロキシ
- アプリケーションサーバ
といった複数コンポーネントを組み合わせる構成に比べ、 Unit ではこれらを統合的に扱うことができるため、 システム全体のオーバーヘッドを抑えられるケースもあったのかもしれません。
利点と注意点
利点として挙げられていた点
- JSON API による設定変更が可能(無停止運用)
- 多言語・異なるバージョンのランタイムの共存
- HTTP サーバとアプリ実行環境の統合による構成の簡素化
- 高並行アクセス時に有利となる可能性
- 起動オーバーヘッドやメモリ使用量の削減が期待できるケース
注意点として指摘されていた点
- マルチテナント環境などでのプロセス分離設計への配慮
- Nginx が持つ高度なリライトルールやロードバランシング機能は限定的
- 運用ノウハウや周辺ツールの成熟度の問題
- 言語拡張やフレームワークによる互換性の制約
- ワークロードによっては効果が限定的
- 主に Linux / BSD 系 OS が対象(Windows 非対応)
Reddit の事例をどう解釈するか
Reddit の投稿では「約 40% のサーバ削減」という結果が報告されていますが、 そのアプリケーション構成やトラフィック特性は明示されていません。
また、他のコメントでは、
- 長時間処理では差が小さい
- すべての場面で高速化するわけではない
といった指摘も見られます。
パフォーマンス改善の要因として プロセス間通信の削減が挙げられているものの、
- キャッシュ効率
- メモリ使用量
- I/O パターン
- アプリケーションの実装
など、複数の要素が影響している可能性もあります。
したがって、この事例は 「特定条件下では改善を実感できたケースがあった」 という参考情報として捉えるのが妥当でしょう。
補足: とりあえず入れてみた
インストール
Installation — NGINX Unit
https://unit.nginx.org/installation/
Amazon Linux / Installation — NGINX Unit
https://unit.nginx.org/installation/#amazon-2023
PHP 8.3 以上はサポートされていないようですので、8.2 以下の環境が必要です。
# php -v
PHP 8.2.21 (cli) (built: Jul 2 2024 12:51:54) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.2.21, Copyright (c) Zend Technologies
with Zend OPcache v8.2.21, Copyright (c), by Zend Technologies
# vi /etc/yum.repos.d/unit.repo
[unit]
name=unit repo
baseurl=https://packages.nginx.org/unit/amzn/2023/$basearch/
gpgkey=https://unit.nginx.org/keys/nginx-keyring.gpg
gpgcheck=1
enabled=1
# yum install unit
# yum install unit-devel unit-jsc17 unit-perl unit-php unit-python39 unit-python311 unit-wasm
# systemctl restart unit
# service unit status
Redirecting to /bin/systemctl status unit.service
● unit.service - NGINX Unit
Loaded: loaded (/usr/lib/systemd/system/unit.service; disabled; preset: disabled)
Active: active (running) since Tue 2026-02-10 03:35:50 JST; 6s ago
Process: 29630 ExecStart=/usr/sbin/unitd $UNITD_OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 29631 (unitd)
Tasks: 3 (limit: 1059)
Memory: 13.1M
CPU: 24ms
CGroup: /system.slice/unit.service
├─29631 "unit: main v1.34.2 [/usr/sbin/unitd --log /var/log/unit/unit.log --pid /var/run/unit/unit.pid]"
├─29633 "unit: controller"
└─29634 "unit: router"
初期設定 (とりあえず動かす)
接続テスト
# curl --unix-socket /run/unit/control.sock http://localhost/
{
"certificates": {},
"js_modules": {},
"config": {
"listeners": {},
"routes": [],
"applications": {}
},
"status": {
"modules": {
"python": [
{
"version": "3.11.2",
"lib": "/usr/lib64/unit/modules/python3.11.unit.so"
},
{
"version": "3.9.16",
"lib": "/usr/lib64/unit/modules/python3.9.unit.so"
}
],
"php": {
"version": "8.2.9",
"lib": "/usr/lib64/unit/modules/php.unit.so"
},
"perl": {
"version": "5.32.1",
"lib": "/usr/lib64/unit/modules/perl.unit.so"
},
"java": {
"version": "17.0.8.1",
"lib": "/usr/lib64/unit/modules/java17.unit.so"
},
"wasm": {
"version": "0.1",
"lib": "/usr/lib64/unit/modules/wasm.unit.so"
},
"wasm-wasi-component": {
"version": "0.1",
"lib": "/usr/lib64/unit/modules/wasm_wasi_component.unit.so"
}
},
"connections": {
"accepted": 0,
"active": 0,
"idle": 0,
"closed": 0
},
"requests": {
"total": 0
},
"applications": {}
}
}
アプリケーション設定の投入
設定ファイルを作成
# cat <<'EOF' > /tmp/config.json
{
"listeners": {
"*:8080": {
"pass": "applications/example"
}
},
"applications": {
"example": {
"type": "php",
"root": "/var/www/example/public_html",
"index": "index.php"
}
}
}
EOF
Unitに反映
# curl -X PUT --data-binary @/tmp/config.json \
--unix-socket /run/unit/control.sock \
http://localhost/config
{
"success": "Reconfiguration done."
}
アプリが登録されたことを確認
# curl --unix-socket /run/unit/control.sock http://localhost/config/
{
"listeners": {
"*:8080": {
"pass": "applications/example"
}
},
"applications": {
"example": {
"type": "php",
"root": "/var/www/example/public_html",
"index": "index.php"
}
}
}
# service mysqld start
# service php-fpm start
ポート8080を開く
ブラウザからアクセス
http://xxx.xxx.xxx.xxx:8080/
画面は崩れているがサイトは表示されました。
確認用コマンドまとめ
| 目的 | コマンド |
|---|---|
| Unit 状態確認 | sudo systemctl status unit |
| 制御ソケット確認 | sudo ls -l /run/unit/control.sock |
| 設定投入 | sudo curl -X PUT --data-binary @/tmp/config.json --unix-socket /run/unit/control.sock http://localhost/config |
| 設定確認 | sudo curl --unix-socket /run/unit/control.sock http://localhost/config/ |
| 稼働テスト | curl http://localhost:8080/ |