PHP 7.3 install problem in tfb-status

[joanhey]

In the last run all failed to install php7.3, and the actual running also have the same problem.

https://tfb-status.techempower.com/unzip/results.2018-12-23-15-04-49-016.zip/results/20181220223653/php-raw7/build/php-raw7.log

Really strange when in travis is working perfectly. Perhaps a problem of any cache ?

[NateBrady23]

It looks like the location of the files in the archive changes? The ones listed in the logs are no longer at that location. Let's see what it does on the next time around.

[joanhey]

php7.3.0-1.... don't exist anymore, now it is php7.3.0-2.....

In travis isn't failing because it recreate the first docker and later use the cache.

Here create it the first time: https://travis-ci.org/TechEmpower/FrameworkBenchmarks/jobs/470580086#L732 And later use the cache: https://travis-ci.org/TechEmpower/FrameworkBenchmarks/jobs/470580086#L861

But the tfb-status use the same cache in any new run: https://tfb-status.techempower.com/unzip/results.2018-12-26-15-03-16-248.zip/results/20181223230515/cakephp/build/cakephp.log

cakephp: Step 4/18 : RUN LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
cakephp:  ---> Using cache
cakephp:  ---> 4e6439e5b859
cakephp: Step 5/18 : RUN apt-get update -yqq  > /dev/null
cakephp:  ---> Using cache

CakePHP is the first framework in tfb-status that install php7.3.

[NateBrady23]

Oh, I see now. I won't be in the office for another week. We bust the cache after a few runs but if it's not busted by the time I go in, I'll do it manually.

[joanhey]

Solved.

Looks like in one run, anybody cleaned the docker cache in the middle of the run. As only the last half of php frameworks installed correctly php.

If the tfb-status don't clean the docker cache before each run, it's very important to indicate in which runs the cache was cleaned.

[NateBrady23]

Good point @joanhey - I don't think we check during the tests, and someone may have done it manually, but will verify with the team on Monday.

[NateBrady23]

@joanhey We don't bust the cache during a run, only between full runs. Not 100% sure what happened during the run that would have made the last half of php frameworks pass. Going to close this for now.

[raziel057]

Do you know why we always got error in some of PHP Frameworks (lumen, symfony, ...) ? Is it related to the cache?

It's visible in the 3 last runs:

• https://www.techempower.com/benchmarks/#section=test&runid=58770c2f-a4bb-478f-8b4b-7ef77e5e25b6
• https://www.techempower.com/benchmarks/#section=test&runid=fcd8886c-e0ff-407c-979c-d93f1f8100ab
• https://www.techempower.com/benchmarks/#section=test&runid=32bf65e3-6553-4adf-8f5e-77c7ff50391c

Errors are presents for benchmarks with database (Single Query, Multiple Queries, Fortunes, Data Updates).

[zloster]

@raziel057 Check out the logs if the frameworks are affected by #4092.

[joanhey]

All the php frameworks that have errors with the db benchmarks, are because don't use persistent connection to the db.

I tried my best to update all the frameworks to use persistent connection, but in some frameworks I can't find how to do it. #3658 And all that changed to use persistent connections, they immediately stopped having errors.

And the logs don't show info about that.

[joanhey]

They just can not connect quickly to the bd. In citrine the database is in another server. Without persistent connection they need to open a new TCP for every db consult. And that is very expensive.

[raziel057]

It’s strange because there were no problem in previous round. Here for example: https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune

[joanhey]

In previous rounds the nginx configuration was not optimized. Only 8 worker_processes, now uses auto (1 worker per CPU core). Citrine have 24 cores.

But the worst was that nginx was using TCP, without keep alive (persistent connection) to the php-fpm. So again, for every request from nginx to php-fpm it's necessary to create a new TCP connection. Now uses keep alive and unix sockets. The unix sockets are faster and the gain using keep alive it's less. But still we have 5 system calls less for every request, with 300.000 req/s x 5 system calls = 1.500.000 system calls per second that are not necessary.

Before simply nginx didn't send enough food (requests) to the php-fpm. Every connection to php-fpm was using a new TCP connection, slow enough to php have time to create a new TCP connection to the bd.

Check the numbers from Round15 vs the last run.

Fortunes:

Framework	Round 15	Last run
Php-raw7	34,595	122,695
Slim	9,081	26,380

Json:

Framework	Round 15	Last run
Php7	38,497	251,106
Slim	17,384	35,439

Always it's recommended to use persistent connections, but a necessity if your database it's in another server. Any website with big traffic, the first recommendation it's separate the bd in another server.

The worst thing, it is that was very difficult to find the info for use persisten connection, in most frameworks. That info will be easy to find and recommended when your bd it's in another server.

And that Doctrine don't permit persistent connection, It's a very wrong technical decision.

PD: @raziel057 the next time open a new issue, because the title of this issue is not about that.

[raziel057]

@joanhey Thanks you for the clarification.

[joanhey]

@raziel057 Check Symfony 700% faster with Workerman.

https://github.com/joanhey/AdapterMan

[raziel057]

@joanhey Wouahou that’s huge! 👍