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.

[docteurklein]

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

[OO00O0O]

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

[docteurklein]

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.

[docteurklein]

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.

[VBart]

@BunnyHolder Yes, static content serving is planned.
Currently, you can utilize nginx or/and cdn for that.

[uasan]

HTTP-caching for application responses in Unit, is planned implement?

[VBart]

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.

[OO00O0O]

@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

[VBart]

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.

[mdesantis]

Hello! I'm interested about Websockets support

[VBart]

There's one https://itnext.io/performance-comparison-between-nginx-unit-and-uwsgi-python3-4511fc172a4c

[stevenh]

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?

[nshadrin]

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.

[mdesantis]

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 <[email protected]> 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 <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARSuGxAuFWzwPQeRorTu7S5kd6kWw2Jks5tr2JIgaJpZM4PPndY> .

[VBart]

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