php: Performance problem on require, require_once, include php statements

Hi all, I’m experimenting bad performance and the problem seems to be when calling require, require_once, include statements.

Here’s a very simple file test.php I used to test the problem. The file simply load 3 files test1.php, test2.php and test3.php.

<?php
$start = microtime(true);
require('./test1.php');
$stop = microtime(true);
echo "require: " . ($stop - $start) . '<br>';

$start = microtime(true);
require_once('./test2.php');
$stop = microtime(true);
echo "require_once: " . ($stop - $start) . '<br>';

$start = microtime(true);
include('./test3.php');
$stop = microtime(true);
echo "include: " . ($stop - $start) . '<br>';

Files test1.php, test2.php and test3.php are as follow:

<?php
echo 1; // 2 and 3 in the corrisponding file

When I call test.php from the container (using the image php:7.0-apache), the response time is 10x worst than when I execute the same simple code directly from the host (same apache and same php7).

I’m using Debian 8 also for the Host and Docker Cloud for orchestration. Here’s the output of “docker info”: Containers: 51 Running: 16 Paused: 0 Stopped: 35 Images: 388 Server Version: 1.11.2-cs5 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 839 Dirperm1 Supported: true Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge null host weavemesh Kernel Version: 3.16.0-4-amd64 Operating System: Debian GNU/Linux 8 (jessie) OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 7.789 GiB Name: xxxxxxx ID: 2PC2:2IGQ:KT26:O4KM:RFID:HUWW:Y2FO:LYSK:MNZR:KXKY:OPFO:G2CX Docker Root Dir: /var/lib/docker Debug mode (client): false Debug mode (server): false Username: xxxxxxxxxx Registry: https://index.docker.io/v1/ WARNING: No memory limit support WARNING: No swap limit support WARNING: No kernel memory limit support WARNING: No oom kill disable support WARNING: No cpu cfs quota support WARNING: No cpu cfs period support

About this issue

Original URL
State: open
Created 7 years ago
Reactions: 1
Comments: 17 (2 by maintainers)

Most upvoted comments

alexmatsak on Nov 16, 2017

I also found it really slow on php-fpm docker image, but if use the ubuntu image, apt install the php-fpm and nginx, everything works well… I dont know why

php7.2-fpm-alpine

  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.59s   366.04ms   1.87s    88.50%
    Req/Sec    29.24     13.61    70.00     70.31%
  574 requests in 10.01s, 1.37MB read
Requests/sec:     57.32
Transfer/sec:    139.60KB

pure ubuntu image and install php manully…

  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   171.79ms   38.81ms 458.92ms   73.56%
    Req/Sec   289.15     70.54   424.00     65.00%
  5762 requests in 10.01s, 13.57MB read
Requests/sec:    575.65
Transfer/sec:      1.36MB

zsimple on Oct 16, 2018

This is very interesting, I wrote a PHP include test tool based on your tests. I’m not entirely sure this is anything to do with the PHP image itself - I believe it’s still an issue of Docker volume mapping performance and the use of file streams.

Here is the test tool: https://github.com/kducharm/phpincludetest - it includes a flag to enable memory test in addition to just the file include tests.

I have Docker For Mac Edge (17.09.0-ce-mac34 19605), as well as VirtualBox running Ubuntu 16.04. With Docker For Mac, the volume mapped test is at least 10x slower than host, and building an image without volume mapping is roughly the same speed as the host. This doesn’t surprise me given the performance issues plaguing Docker For Mac volumes, but is pretty bad.

In Ubuntu under VirtualBox on Mac, running docker (inception…) - host/volume mapped/image all perform roughly the same as host/image on Docker For Mac. I haven’t tested Ubuntu enough to know what to expect, but it looks pretty performant.

I’ll probably share this testing tool on docker forums, and would be good to augment it with other file I/O tests. This is only a single container test, and I’ve been experiencing bad performance with DB containers on Mac and Ubuntu and need to narrow it down to file I/O or some other multip[le container/volume mapping issue.

Docker machine w/NFS runs way faster on Mac than Docker For Mac currently for me, which is not good.

kducharm on Dec 2, 2017

@alexmatsak can you provide docker info too.

bweston92 on Nov 16, 2017

Same problem here…

imagina on Feb 14, 2019

Containers: 39
 Running: 26
 Paused: 0
 Stopped: 13
Images: 277
Server Version: 17.09.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 3f2f8b84a77f73d38244dd690525642a72156c64
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.49-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.786GiB
Name: moby
ID: YDAN:WISP:BGZE:GZV2:CA6S:QRIH:ENOH:3QDF:IQAR:IH6B:NTNL:WDA2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 265
 Goroutines: 330
 System Time: 2017-11-16T14:10:22.2311708Z
 EventsListeners: 2
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

alexmatsak on Nov 16, 2017

@tianon I tried with 1) a volume/bind mount and 2) with files created on the fly inside the container after I started it without a volume. I had the same differences between the host and container results in both cases. I didn’t try with a new image with these files stored inside.

I also installed a fresh new debian 8 on a PC and replicated the test on the host and in the container. Same results as on the precedent host.

By the way, if I compare performance for other kind of statements (i.e. using memory), the results are instead quite the same in the host and the container. For example:

<?php

$start = microtime(true);

for($i=0; $i < 1000000; $i++){
        $j[] = $i;
}

$stop = microtime(true);
echo "require: " . ($stop - $start) . '<br>';

This point has been also verified comparing results between the host and the container of this php benchmark.

MarcelloOr on Sep 19, 2017