Please, describe in more detail in readme, your advantages in comparison with similar Application servers.
For example PHP:
Thanks.
Same for go it seems to be adding an extra layer without adding any real benefit that I can see?
The only thing seems to be dynamic reconfiguration which can already be done with just straight nginx.
Am I missing something?
What I can see now is the Application model and the JSON API which remind me to Webfaction application model - https://docs.webfaction.com/xmlrpc-api/apiref.html#applications
The application model and the http API would allow us to build something like webfaction hosting panel.
Hi, I want to understand the benefit of using Unit. In case of Python, how it's better than just running e.g. multiple tornado backends on supervisord/monit/whatever and having nginx server in front of it?
I'll use this issue to dump my early benchmarks (not saying it's correct and definitive, but I still think it worths sharing).
Maybe my config is not optimal, and in that case it's great in the sense it might open a discussion on how to make it better.
Anyway, I tried to compare an nginx(epoll,multi_accept on) + php-fpm(dynamic pool at max-workers=70) with a nginx-unit php application with 70 workers, serving the same php application (complicated real-life symfony application with pdo_mysql and redis access and stuff).
I used wrk to bench it (4 threads, 10 connections during 20s), here are the results:
% wrk --timeout=20 --latency -H "Authorization: Bearer $TOKEN" -t4 -c10 -d20s 'http://127.0.0.1:8080/en/contents'
Running 20s test @ http://127.0.0.1:8080/en/contents
4 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 53.20ms 22.25ms 146.78ms 65.08%
Req/Sec 37.55 11.16 80.00 63.38%
Latency Distribution
50% 59.99ms
75% 66.66ms
90% 74.78ms
99% 99.82ms
3006 requests in 20.02s, 441.43MB read
Requests/sec: 150.14
Transfer/sec: 22.05MB
% wrk --timeout=20 --latency -H "Authorization: Bearer $TOKEN" -t4 -c10 -d20s 'http://127.0.0.1:8300/en/contents'
Running 20s test @ http://127.0.0.1:8300/en/contents
4 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 108.47ms 15.14ms 247.84ms 74.57%
Req/Sec 18.44 4.31 30.00 79.47%
Latency Distribution
50% 106.93ms
75% 116.66ms
90% 125.13ms
99% 142.14ms
1467 requests in 20.01s, 215.16MB read
Socket errors: connect 0, read 1467, write 0, timeout 0
Requests/sec: 73.30
Transfer/sec: 10.75MB
I noticed some strange CPU usage (1 core was 100% used by unit after the bench was finished, even with 0 traffic).
Hope it helps! I know benchmarks are are often bad, I'm not here to open a war :) just sharing.
PS:
{
"listeners": {
"*:8300": {
"application": "api"
}
},
"applications": {
"api": {
"type": "php",
"workers": 70,
"root": "/usr/src/app/web",
"index": "app.php",
"script": "app.php"
}
}
}
[global]
daemonize = no
error_log = /proc/self/fd/2
[www]
listen = [::]:9000
access.log = /proc/self/fd/2
clear_env = no
catch_workers_output = yes
pm = dynamic
pm.max_children = 70
pm.start_servers = 40
pm.min_spare_servers = 40
pm.max_spare_servers = 50
;pm.max_requests = 500
pm.status_path = /fpm_status
ping.path = /ping
```
user nginx;
worker_processes auto;
error_log /dev/stderr debug;
pid /var/run/nginx.pid;
events {
worker_connections 4096;
multi_accept on;
use epoll;
}
worker_rlimit_nofile 40000;
http {
access_log /dev/stdout;
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format proxy '[$time_local] response_time: $upstream_response_time - status: $upstream_status: "$request"';
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_requests 100000;
send_timeout 60;
client_header_timeout 60;
client_body_timeout 60;
proxy_send_timeout 60;
proxy_connect_timeout 60;
proxy_read_timeout 60;
fastcgi_send_timeout 60;
fastcgi_connect_timeout 60;
fastcgi_read_timeout 60;
reset_timedout_connection on;
gzip on;
gzip_vary on;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/javascript application/json application/xml;
gzip_disable "MSIE [1-6].";
open_file_cache max=2000 inactive=20s;
open_file_cache_valid 60s;
open_file_cache_min_uses 5;
open_file_cache_errors off;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Connection "";
proxy_buffering off;
proxy_buffer_size 128k;
proxy_buffers 100 128k;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 16k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_keep_conn on;
upstream fpm {
server api_php_fpm:9000;
keepalive 128;
}
server {
listen 80 default_server;
root /usr/src/app/web;
location /ping {
include fastcgi_params;
fastcgi_pass fpm;
}
location / {
add_header 'Access-Control-Allow-Origin' '*';
try_files $uri /app.php$is_args$args;
}
location ~ ^/(app|app_dev|config)\.php(/|$) {
access_log /dev/stdout proxy;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /usr/src/app/web/app.php;
fastcgi_pass fpm;
}
}
}
Responding to OP:
Competitive advantages are coming in the form of:
Consistent application delivery stack regardless of the language used. That is the ability to run PHP, Python, Go (and other languages later) with the same HTTP stack and configuration methods.
Dynamic application configuration. Unit does not reload on changes. Only the parts that require restarting (such as application workers) - are restarted on demand. This greatly saves resources and gives you the ability to reconfigure as frequently as you like.
Regarding performance testing:
Currently it's too early to for the performance tests. Unit is still in beta, and it has some early features and early versions of the code in many places.
Configuration for tuning is also not available yet.
Be sure, it will be optimized closer to the stable release.
I encourage the community to work with us on optimizing the code, and treat the current performance tests as experiments only.
@docteurklein Actually, the architecture is the best of the best from a performance point of view. There are no compromises. But on the current development stage the code isn't in a good enough shape to show impressive numbers.
yes, the embedded php SAPI seems a good idea and could be a huge win from a performance POV I guess.
I really like the idea behind unit, and it could be a good replacement for the nginx+fpm stack.
Again, I was just sharing some numbers (as the OP asked in point 1) and some default config to help people who might later need it.
@docteurklein I feel your benchmarks are invalid because you are comparing apples to oranges. You benched raw unitd to nginx+fpm. Your comparisons need to be nginx+unitd and nginx+fpm, or straight fpm and unitd.
While its not quite the same I doubt adding an extra nginx layer in front of unitd will improve throughput?
Also you can't benchmark fpm with standard tools as its fastcgi based not http.
@techhelper1 I tend to agree with @stevenh since unitd is meant to replace nginx for the http layer, and based on http://unit.nginx.org/docs-integration-with-nginx.html, nginx should only be used to handle static file serving.
@docteurklein So, nginx for static, unit for dynamic? Like how I'm gonna run Symfony website with all images and stuff? I will still need nginx, or unit will have some "static content serving". If it does, will we won't need nginx/apache for simple wordpress sites?
ATM, I think you'll need nginx for static assets only, and a proxy_pass to unitd for the rest. I don't know if unitd plans static assets serving at all.
Maybe an alternative solution would be to make a unitd go app that does only static serving: https://gowebexamples.com/static-files/
never tried tho.
@BunnyHolder Yes, static content serving is planned.
Currently, you can utilize nginx or/and cdn for that.
HTTP-caching for application responses in Unit, is planned implement?
Not for the nearest future, but I would say that in general we are working on reducing complexity of web technology stack and therefore reducing number of different components that you have to deal with.
@VBart so idea is to do http server with compilers as plugins? Like: apt install unit unit-php7, and i'm good to go, or I have install php separately? Can config be in project? It would be nice to have ability to register config: nginx-unit register /some/path/to/project/unit.json ProjectName && nginx-unit start ProjectName
apt install unit unit-php7, and i'm good to go, or I have install php separately?
apt handles all the dependencies automatically, so you don't have to install php separately.
Can config be in project?
Yes. It's up to you where and how to keep your configuration.
It would be nice to have ability to register config: nginx-unit register /some/path/to/project/unit.json ProjectName && nginx-unit start ProjectName
Since Unit has a simple RESTful JSON API, then it can be just a curl command, or a php script in your application that you run to register itself.
Hello! I'm interested about Websockets support
Improvement from uwsgi but whats the benefit for go, you still need nginx in front of that so seems like just another layer to get in the way?
The reasons to use Unit for a Go app would be related to consistency and ease of management across your various app implementations.
Can I ask about web sockets again? I think it's crucial for modern web
environments
Maurizio De Santis
Il mar 24 apr 2018, 19:35 Nick Shadrin notifications@github.com ha
scritto:
The reasons to use Unit for a Go app would be related to consistency and
ease of management across your various app implementations.
- You will use the same provisioning and deployment for your Python
app as you will do for a Go app or any other app.- Your HTTP operation will be the same for all your apps, and it
simplifies troubleshooting.- You can decouple the network connectivity and configuration from the
app code in the same way for all apps.- You can manage your Go app dynamically, remotely, with zero
downtime. Upgrade the versions of the app, try its operation with various
traffic patterns, stop, start, use several versions at the same time for
canary or blue/green deployments, etc.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nginx/unit/issues/6#issuecomment-384017103, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARSuGxAuFWzwPQeRorTu7S5kd6kWw2Jks5tr2JIgaJpZM4PPndY
.
@mdesantis Support for WebSockets is planned. It's a complex feature, so it's hard to specify exact ETA until R&D will be done. You can help to shape it out by proposing a good interface for working with WebSockets in Unit.
@dalu The architecture of Unit allows it to be the fastest server for web applications. If in some tests it's slower, then it's a bug.
There are people who tested PHP in one of Unit betas and got good numbers:
https://community.centminmod.com/threads/nginxs-unit.12803/
PHP opcode caching is available for embed SAPI, but it should be enabled in php.ini (which is usually located on different path than php.ini for php-fpm).
Last time I've compared Unit with nginx+php-fpm running phpinfo(), I got the numbers below.
nginx+php-fpm:
% wrk -t 8 -d 30s -c 64 --latency http://127.0.0.1:7000/phpinfo.php
Running 30s test @ http://127.0.0.1:7000/phpinfo.php
8 threads and 64 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 10.80ms 598.04us 16.44ms 82.60%
Req/Sec 744.22 35.77 1.38k 81.92%
Latency Distribution
50% 10.77ms
75% 11.04ms
90% 11.35ms
99% 12.77ms
177839 requests in 30.05s, 10.18GB read
Requests/sec: 5917.94
Transfer/sec: 346.99MB
Unit:
% wrk -t 8 -d 30s -c 64 --latency http://127.0.0.1:9001/phpinfo.php
Running 30s test @ http://127.0.0.1:9001/phpinfo.php
8 threads and 64 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 7.66ms 1.97ms 153.96ms 99.54%
Req/Sec 1.06k 97.64 1.83k 78.75%
Latency Distribution
50% 7.25ms
75% 7.92ms
90% 8.81ms
99% 8.92ms
252092 requests in 30.05s, 13.96GB read
Requests/sec: 8389.86
Transfer/sec: 475.84MB
I've benchmarked with Unit alone (not nginx + Unit), because that's how it's supposed to be used eventually when it will have all the required web features.
The code in some performance critical places still isn't mature and there are many opportunities for further optimizations.
Support for WebSockets is planned. It's a complex feature, so it's hard to specify exact ETA until R&D will be done. You can help to shape it out by proposing a good interface for working with WebSockets in Unit.
Ideally, I want to have all the functionality as Nchan for Nginx, out of the box Unit.
Plus https://github.com/nginx/unit/issues/81
Thanks.
I've benchmarked with Unit alone (not nginx + Unit), because that's how it's supposed to be used eventually when it will have all the required web features.
Looking forward to when Nginx Unit has web feature parity with Nginx web server :)
Performance numbers are needed for nginx-unit-php vs php-fpm (5+7.{1,2}) and nginx-unit-go vs plain go
Guess I will have to revisit my PHP-FPM benchmarks like https://community.centminmod.com/threads/php-7-2-0-ga-stable-vs-php-7-1-12-vs-7-0-26-vs-5-6-32-benchmarks.13590/#post-57672 and add Nginx Unit based PHP into the equation.
@VBart but one thing I am curious about is PHP-FPM and fastcgi_cache in Nginx versus Nginx Unit native PHP ? Is there anything in Nginx Unit native PHP planned for similar to PHP-FPM and fastcgi_cache feature ? For example Vanilla forum with Nginx + PHP-FPM with fastcgi_cache performed 42x times faster than PHP-FPM without fastcgi_cache https://community.centminmod.com/threads/vanilla-forums-2-5-1-vhost-configuration.14335/#post-61464. Nginx Unit native PHP while seems to perform better, won't go anywhere near matching fastcgi_cache based PHP-FPM.
@centminmod Yes, caching features are planned too.
I got such a low performance number to use Unit for a Go app. Am I did anything wrong?
package main
import (
"net/http"
"nginx/unit"
)
func handler(a http.ResponseWriter, b *http.Request) {
a.Write([]byte("xxxxxxx."))
}
func main() {
http.HandleFunc("/", handler)
unit.ListenAndServe(":8700", nil)
}
❯ wrk -t12 -c12 -d30s -T30s --latency 'http://localhost:8700' z@master1
Running 30s test @ http://localhost:8700
12 threads and 12 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 579.06us 233.66us 11.09ms 73.25%
Req/Sec 1.74k 572.05 4.40k 60.58%
Latency Distribution
50% 497.00us
75% 754.00us
90% 0.88ms
99% 1.18ms
623052 requests in 30.10s, 95.07MB read
Requests/sec: 20700.73
Transfer/sec: 3.16MB
package main
import (
"net/http"
)
func handler(a http.ResponseWriter, b *http.Request) {
a.Write([]byte("idevz go."))
}
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8800", nil)
}
❯ wrk -t12 -c12 -d30s -T30s --latency 'http://localhost:8800' z@master1
Running 30s test @ http://localhost:8800
12 threads and 12 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 550.32us 1.55ms 30.27ms 93.77%
Req/Sec 5.84k 1.77k 11.03k 70.09%
Latency Distribution
50% 150.00us
75% 257.00us
90% 749.00us
99% 8.61ms
2095392 requests in 30.09s, 249.79MB read
Requests/sec: 69627.65
Transfer/sec: 8.30MB
@mar0x please look above ^^^. It looks like a bug in the Go module.
Some more tests on very similar servers. I think the developers will be interested to see ... Unfortunately, while there is no possibility to look at completely identical versions of php, as I can - I will publish.
| PHP BENCHMARK SCRIPT |
-------------------------------------------------------------------------------------------
Start : 2018-11-26 19:03:20
Server : Linux/3.16.0-4-amd64 x86_64
Platform : Linux
CPU :
model : Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
cores : 1
MHz : 2299.998MHz
Memory : 64 Mb available
Benchmark version : 1.0.32
PHP version : 7.0.32-1~dotdeb+8.1
available modules :
mbstring : yes
json : yes
xmlrpc : no
pcre : yes
Max execution time : 30 sec
Crypt hash algo : MD5
-------------------------------------------------------------------------------------------
TEST NAME : SECONDS | OP/SEC | OP/SEC/MHz | MEMORY
-------------------------------------------------------------------------------------------
01_math : 2.567 sec | 37.44 kOp/s | 16.28 Ops/MHz | 2 Mb
02_string_concat : 0.080 sec | 5.77 MOp/s | 2.51 kOps/MHz | 2 Mb
03_1_string_number_concat : 0.442 sec | 776.65 kOp/s | 337.67 Ops/MHz | 2 Mb
03_2_string_number_format : 0.380 sec | 903.57 kOp/s | 392.86 Ops/MHz | 2 Mb
04_string_simple_functions : 1.100 sec | 81.12 kOp/s | 35.27 Ops/MHz | 2 Mb
05_string_multibyte : 0.919 sec | 9.71 kOp/s | 4.22 Ops/MHz | 2 Mb
06_string_manipulation : 1.162 sec | 76.81 kOp/s | 33.40 Ops/MHz | 2 Mb
07_regex : 0.648 sec | 137.67 kOp/s | 59.86 Ops/MHz | 2 Mb
08_1_hashing : 0.751 sec | 118.75 kOp/s | 51.63 Ops/MHz | 2 Mb
08_2_crypt : 1.151 sec | 596.20 Op/s | 0.26 Ops/MHz | 2 Mb
09_json_encode : 1.279 sec | 69.75 kOp/s | 30.32 Ops/MHz | 2 Mb
10_json_decode : 1.465 sec | 60.91 kOp/s | 26.48 Ops/MHz | 2 Mb
11_serialize : 1.178 sec | 75.72 kOp/s | 32.92 Ops/MHz | 2 Mb
12_unserialize : 1.301 sec | 68.56 kOp/s | 29.81 Ops/MHz | 2 Mb
13_array_fill : 0.978 sec | 3.72 MOp/s | 1.62 kOps/MHz | 2 Mb
14_array_range : 0.105 sec | 278.34 kOp/s | 121.02 Ops/MHz | 2 Mb
14_array_unset : 0.848 sec | 4.29 MOp/s | 1.87 kOps/MHz | 2 Mb
15_loops : 1.587 sec | 16.44 MOp/s | 7.15 kOps/MHz | 2 Mb
16_loop_ifelse : 1.237 sec | 4.99 MOp/s | 2.17 kOps/MHz | 2 Mb
17_loop_ternary : 2.248 sec | 2.75 MOp/s | 1.19 kOps/MHz | 2 Mb
18_1_loop_defined_access : 0.298 sec | 4.61 MOp/s | 2.00 kOps/MHz | 2 Mb
18_2_loop_undefined_access : 1.320 sec | 1.04 MOp/s | 452.21 Ops/MHz | 2 Mb
19_type_functions : 4.064 sec | 84.44 kOp/s | 36.71 Ops/MHz | 2 Mb
20_type_conversion : 0.545 sec | 629.55 kOp/s | 273.72 Ops/MHz | 2 Mb
21_0_loop_exception_none : 0.045 sec | 6.17 MOp/s | 2.68 kOps/MHz | 2 Mb
21_1_loop_exception_try : 0.048 sec | 5.75 MOp/s | 2.50 kOps/MHz | 2 Mb
21_2_loop_exception_catch : 4.356 sec | 63.02 kOp/s | 27.40 Ops/MHz | 2 Mb
22_loop_null_op : 0.920 sec | 3.73 MOp/s | 1.62 kOps/MHz | 2 Mb
23_loop_spaceship_op : 0.783 sec | 4.38 MOp/s | 1.91 kOps/MHz | 2 Mb
24_xmlrpc_encode : -.--- sec | -.--Op/s | -.--Ops/MHz | 0
25_xmlrpc_decode : -.--- sec | -.--Op/s | -.--Ops/MHz | 0
-------------------------------------------------------------------------------------------
Total time: : 33.802 sec | 1.51 MOp/s | 657.86 Ops/MHz |
Current PHP memory usage: : 2 Mb
Peak PHP memory usage: : 2.18 Mb
| PHP BENCHMARK SCRIPT |
-------------------------------------------------------------------------------------------
Start : 2018-11-26 19:04:14
Server : Linux/4.9.0-8-amd64 x86_64
Platform : Linux
CPU :
model : QEMU Virtual CPU version 2.5+
cores : 1
MHz : 2799.998MHz
Memory : 64 Mb available
Benchmark version : 1.0.32
PHP version : 7.2.12-1+0~20181112102304.11+stretch~1.gbp55f215
available modules :
mbstring : yes
json : yes
xmlrpc : no
pcre : yes
Max execution time : 30 sec
Crypt hash algo : MD5
-------------------------------------------------------------------------------------------
TEST NAME : SECONDS | OP/SEC | OP/SEC/MHz | MEMORY
-------------------------------------------------------------------------------------------
01_math : 1.828 sec | 185.78 kOp/s | 66.35 Ops/MHz | 2 Mb
02_string_concat : 0.017 sec | 97.48 MOp/s | 34.81 kOps/MHz | 2 Mb
03_1_string_number_concat : 0.015 sec | 81.79 MOp/s | 29.21 kOps/MHz | 2 Mb
03_2_string_number_format : 0.011 sec | 110.92 MOp/s | 39.61 kOps/MHz | 2 Mb
04_string_simple_functions : 1.215 sec | 259.48 kOp/s | 92.67 Ops/MHz | 2 Mb
05_string_multibyte : 2.840 sec | 11.10 kOp/s | 3.97 Ops/MHz | 2 Mb
06_string_manipulation : 2.100 sec | 150.16 kOp/s | 53.63 Ops/MHz | 2 Mb
07_regex : 1.226 sec | 257.21 kOp/s | 91.86 Ops/MHz | 2 Mb
08_1_hashing : 1.231 sec | 256.11 kOp/s | 91.47 Ops/MHz | 2 Mb
08_2_crypt : 3.686 sec | 657.84 Op/s | 0.23 Ops/MHz | 2 Mb
09_json_encode : 1.468 sec | 214.83 kOp/s | 76.72 Ops/MHz | 2 Mb
10_json_decode : 2.408 sec | 130.97 kOp/s | 46.78 Ops/MHz | 2 Mb
11_serialize : 1.154 sec | 273.25 kOp/s | 97.59 Ops/MHz | 2 Mb
12_unserialize : 2.019 sec | 156.18 kOp/s | 55.78 Ops/MHz | 2 Mb
13_array_fill : 1.150 sec | 11.19 MOp/s | 4.00 kOps/MHz | 2 Mb
14_array_range : 0.190 sec | 542.35 kOp/s | 193.70 Ops/MHz | 2 Mb
14_array_unset : 1.178 sec | 10.93 MOp/s | 3.90 kOps/MHz | 2 Mb
15_loops : 1.082 sec | 85.16 MOp/s | 30.41 kOps/MHz | 2 Mb
16_loop_ifelse : 0.615 sec | 35.50 MOp/s | 12.68 kOps/MHz | 2 Mb
17_loop_ternary : 1.740 sec | 12.55 MOp/s | 4.48 kOps/MHz | 2 Mb
18_1_loop_defined_access : 0.232 sec | 20.92 MOp/s | 7.47 kOps/MHz | 2 Mb
18_2_loop_undefined_access : 2.249 sec | 2.16 MOp/s | 770.39 Ops/MHz | 2 Mb
19_type_functions : 0.802 sec | 1.51 MOp/s | 539.86 Ops/MHz | 2 Mb
20_type_conversion : 0.780 sec | 1.55 MOp/s | 555.20 Ops/MHz | 2 Mb
21_0_loop_exception_none : 0.009 sec | 105.51 MOp/s | 37.68 kOps/MHz | 2 Mb
21_1_loop_exception_try : 0.022 sec | 43.47 MOp/s | 15.53 kOps/MHz | 2 Mb
21_2_loop_exception_catch : 1.061 sec | 914.92 kOp/s | 326.76 Ops/MHz | 2 Mb
22_loop_null_op : 0.713 sec | 17.02 MOp/s | 6.08 kOps/MHz | 2 Mb
23_loop_spaceship_op : 0.899 sec | 13.49 MOp/s | 4.82 kOps/MHz | 2 Mb
24_xmlrpc_encode : -.--- sec | -.--Op/s | -.--Ops/MHz | 0
25_xmlrpc_decode : -.--- sec | -.--Op/s | -.--Ops/MHz | 0
-------------------------------------------------------------------------------------------
Total time: : 33.942 sec | 5.33 MOp/s | 1.90 kOps/MHz |
Current PHP memory usage: : 2 Mb
Peak PHP memory usage: : 1.46 Mb
Test script from this repo: https://github.com/rusoft/php-simple-benchmark-script
The test was run via a web server with the following parameters: bench.php?memory_limit=64&time_limit=30
Most helpful comment
@dalu The architecture of Unit allows it to be the fastest server for web applications. If in some tests it's slower, then it's a bug.
There are people who tested PHP in one of Unit betas and got good numbers:
https://community.centminmod.com/threads/nginxs-unit.12803/
PHP opcode caching is available for embed SAPI, but it should be enabled in php.ini (which is usually located on different path than php.ini for php-fpm).
Last time I've compared Unit with nginx+php-fpm running
phpinfo(), I got the numbers below.nginx+php-fpm:
Unit:
I've benchmarked with Unit alone (not nginx + Unit), because that's how it's supposed to be used eventually when it will have all the required web features.
The code in some performance critical places still isn't mature and there are many opportunities for further optimizations.