What competitive advantages?

[uasan]

Please, describe in more detail in readme, your advantages in comparison with similar Application servers.

For example PHP:

1. Is it faster than PHP-FPM?
2. Is it better scaled than PHP-FPM?
3. Is it planned that the php script will work in the daemon mode, do not reset the state after HTTP request executed?
4. Is planned implement Websocket protocol?

Thanks.

[stevenh]

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?

[k4ml]

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.

[vovanec]

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?

[docteurklein]

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:

nginx+fpm:

 % 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

nginx-unit php app

 % 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:

the nginx-unit config:

{
    "listeners": {
        "*:8300": {
            "application": "api"
        }
    },
    "applications": {
        "api": {
            "type": "php",
            "workers": 70,
            "root": "/usr/src/app/web",
            "index": "app.php",
            "script": "app.php"
        }
    }
}

fpm config:

[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

nginx config

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;
        }
    }
}

[nshadrin]

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.

[nshadrin]

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.

[VBart]

@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.

[docteurklein]

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.

[MrHamel]

@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.

[stevenh]

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.