In 2002 I started an online game (based on Grand Theft Auto III), which became a successful multiplayer gamemode and finally transformed to a samp game mode in 2006 and is still alive and beeing played by thousands of users every month.
Now after 16 years it's time to say goodbye. The site will shutdown on 20th of may 2018. All data will be removed and destroyed.
If you use the official docker image for php and want to modify e.g. max_post_body_size, you might come to the
conclusion that adding a custom php.ini might be the only solution.
In terms of the 12factor app manifest, this is kind of disappointing, since they promote usage of environment variables for deployment specific configuration.
When trying to enable my php application to be configurable like this, I found multiple ways how to make this possible and want to share those with you.
Today I was working on a php development environment using docker on MacOSX (you might run into the same problems on windows, too!). The osxfs in Docker for Mac is painfully slow and the company behind docker is actually aware of that. At #77 they track the issue at docker-for-mac right now. At the time of writing the ticket is still open.
If you happen to use symfony as PHP framework or in particular composer as package manager for php projects, you end up
with a very big directory called vendor.
In symfony standard edition I am counting 10259 files and folders.
For this blog post I put a vanilla symfony 3.2.7 project at DracoBlue/symfony-composer-docker-performance-test.
With this commit
I added a docker-compose.yml and a nginx.conf to run app.php on http://app.locahost.me:8080 and
app_dev.php on http://dev.locahost.me:8080.
If you run a quick benchmark against app_dev.php:
$ ab -n 1000 -c 16 http://dev.localtest.me:8080/
Concurrency Level: 16
Time taken for tests: 319.303 seconds
Complete requests: 1000
Failed requests: 0
Requests per second: 3.13 [#/sec] (mean)
Time per request: 5108.845 [ms] (mean)
Time per request: 319.303 [ms] (mean, across all concurrent requests)
Transfer rate: 131.33 [Kbytes/sec] received
you end up with response times for a vanilla symfony project of round about 319ms.
The app.php:
$ ab -n 1000 -c 16 http://app.localtest.me:8080/
Concurrency Level: 16
Time taken for tests: 86.140 seconds
Complete requests: 1000
Failed requests: 0
Requests per second: 11.61 [#/sec] (mean)
Time per request: 1378.234 [ms] (mean)
Time per request: 86.140 [ms] (mean, across all concurrent requests)
Transfer rate: 54.50 [Kbytes/sec] received
looks better (86ms), but is not very convenient for development.
Let's tune this with a simple trick down to 46ms (-85%) for app_dev.php and down to 9ms (-88%) for app.php.
While I was working on lua-native-ssi-nginx (an opinionated lua replacement of nginx's ssi directive), I ran into the following issue:
The
proxy_passrequests seemed to hang (or lock) as soon as the response was too big.
Even with nginx in debug mode, I could only see this in the error.log:
2016/10/08 10:47:19 [debug] 31895#0: *1337 http upstream request: "/sub-request?"
2016/10/08 10:47:19 [debug] 31895#0: *1337 http upstream dummy handler
2016/10/08 10:47:19 [debug] 31895#0: *1337 http upstream request: "/sub-request?"
2016/10/08 10:47:19 [debug] 31895#0: *1337 http upstream dummy handler
2016/10/08 10:47:19 [debug] 31895#0: *1337 http upstream request: "/sub-request?"
When Sam Newman's book (280 pages) on microservices was released in the first month of january 2015, I was already reading a preview edition for some weeks. Having the book as paper version next to my desk, let's me open it once in a while to find a good example for a concept or a piece of software for my microservices day work.
The book is not about indepth knowledge about every part of hosting lots of little connected systems, but gives such an awesome overview about all parts, that I can encourage everybody maintaining or creating systems and libraries to read this book!
