All files are named as follows: __c.dat Test types: hhvm - run the tests against HHVM with our production configuration baseline - barebones php-fpm config with just 16 workers maxch40 - same as baseline, but with max workers set to 40 maxch40_static - same as maxch40, but with pm = static opcache1 - same as maxch40, but with a larger opcache space (256 MB) opcache2 - same as opcache1, plus revalidate_freq at 60 seconds and opcache.max_accelerated_files = 24000 opcache3 - same as opcache2, plus opcache.validate_timestamps=0 [this would BREAK our releases right now] maxch80 - same as opcache2, with 80 workers. maxch80_static - same as maxch80, with pm=static sock - same as maxch80, using a unix socket for fastcgi instead of tcp. sock60 - same as sock, but with max_workers = 60 Pages: load - a css served through load.php main_page - English Wikipedia main page heavy_page - English Wikipedia Barack Obama page, no forced re-rendering re-parse - English Wikipedia forced re-rendering of the Australia page, via api.php light_page - Italian Wikipedia page for Nemico Pubblico (film 1998) All were tested with concurrencies between 10 and 40. The raw data files are in this directory. A cleaned version of those files, including only the timestamp and the total response time are included. In these files we removed either the first 5% or requests, or the first 10 seconds of data (whichever was smaller) to account for possible warmup effects. We also remove the top 1% in terms of response times for allowing easier automatic generation of graphs. Graphs were generated starting from said clean files, creating three group of graphs: - "workers" where we show the effect of setting pm = static or pm = dynamic in php7, using HHVM as a baseline. The results are that pm=dynamic consistently outperforms pm=static across the board - contrary to what the literature believes. The result was so strange that I even did a second run with pm=dynamic for confirmation, expecting some performance regression somewhere else in the stack could've caused this result. - "opcache" where we show the effect of different opcache settings. While setting the refresh interval a bit higher gave a net effect, quite oddly disabling the opcache refresh altogether didn't give any advantage. - "high_workers" shows a few different plausible settings for max_workers for a production server: either 2*processorcount or 1.5*processorcount, and also different connection methods between the HTTPD daemon and the fcgi appserver. Unsurprisingly connecting via socket shaves some latency in general; a bit more surprisingly, performace of php-fpm degrades less at high concurrency when connecting via a unix socket