Unit: What competitive advantages?

Created on 7 Sep 2017  ·  32Comments  ·  Source: nginx/unit

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.

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:

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

All 32 comments

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:

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

}

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.

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

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?

with Unit (just one go processes as the standard demo below):

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

with standard go:

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

|                                  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

unit

|                                  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

Was this page helpful?
0 / 5 - 0 ratings