dracoblue.net

When you are using helm and kubernetes to maintain your service workload, you might run into the question: what will be I execute kubectl apply, helm upgrade or helm install. There are multiple native ways, plugins and combined efforts to make this possible.

TLDR:

1. helm diff does only show changes between last helm revision and the new one
2. if you need to show diff between status quo in k8s and what helm would apply, combine helm template or helm upgrade --dry-run output with kubectl diff in --serverside=false mode. But in this case you have to ignore all fieldsType: FieldsV1 and related f: fields if you only want to see the real changes.

Last year I wrote about how lsyncd might improve the development performance of your docker based php development environment using docker on MacOSX (you might run into the same problems on windows, too!). Since 17.04.0-ce the feature :cached is available, which improves the development speed noticably.

Please see the initial post for more details. Since some of my colleagues are still wondering what's making their development environments slow, I put some hints in place which might be even helpful if you are not using docker for development!

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.