New Pi Dramble benchmarks - 2019 Kubernetes edition

[geerlingguy]

A new year, a new architecture... and a new set of benchmarks are required. Stemming from https://github.com/geerlingguy/drupal-for-kubernetes/issues/9, I need to update the Drupal Benchmarks page on the Wiki (see the 'Coming soon!' section).

(Also, delete the 'Unless otherwise stated...' part at the beginning of the page.)

[geerlingguy]

Drupal Version	Setup	Page	Req/s
8.6.10	Pi Dramble K8s, Nginx load balancer, cached	/ page	5124.41
8.6.10	Pi Dramble K8s, Nginx load balancer, not cached	/ page	84.75
8.6.10	Pi Dramble K8s, no load balancer*, anonymous	/ page	88.09
8.6.10	Pi Dramble K8s, no load balancer*, authenticated	/ page	26.26

*'no load balancer' means the domain 'cluster.pidramble.test' was directed straight at the IP of kube2, so all requests were routed through one of the 3 Pi nodes (and then routed internally through Kubernetes' network) instead of being distributed among the three.

[geerlingguy]

(Also, since HPA needs a minute or so to warm up, I'm running the Wiki benchmarks, but three times in a row before the three runs which determine the final metric.)

[geerlingguy]

Locally on my MacBook Pro

Drupal Version	Setup	Page	Req/s
8.6.10	Pi Dramble K8s, Nginx load balancer, cached	/ page	873.80
8.6.10	Pi Dramble K8s, Nginx load balancer, not cached	/ page	34.26
8.6.10	Pi Dramble K8s, no load balancer*, anonymous	/ page	42.46
8.6.10	Pi Dramble K8s, no load balancer*, authenticated	/ page	21.31

Notes

• To run the Nginx load balancer in front, I used:

  docker run -d -p 80:80 -v $PWD/lb.conf:/etc/nginx/conf.d/default.conf:ro nginx

  (And lb.conf contained the following:)

  proxy_cache_path /var/cache/nginx keys_zone=cache:32m max_size=1g inactive=15m;
  
  map $http_cookie $drupal_logged_in {
    default 0;
    ~SESS 1;
  }
  
  upstream backend {
    server 192.168.77.3 max_fails=3;
    server 192.168.77.4 max_fails=3;
    server 192.168.77.5 max_fails=3;
  }
  
  server {
    listen 80 default;
  
    gzip on;
    gzip_static on;
  
    proxy_cache cache;
    proxy_cache_key $scheme$host$uri$is_args$args;
  
    location / {
        proxy_pass http://backend;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $host;
        proxy_redirect off;
  
        proxy_cache_bypass $drupal_logged_in $http_cache_control;
        proxy_no_cache $drupal_logged_in $arg_nocache$arg_page;
        proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
        add_header X-Proxy-Cache $upstream_cache_status;
   }
  }

• Multiple-host VirtualBox and Kubernetes on a 4-core MacBook Pro is... shaky. I found that if I set 1 CPU core per VM, things actually ran slightly faster than giving 2 CPU cores per VM... but that creates a ton of memory pressure inside Kubernetes. But it was extremely consistent. However, since I want to better emulate the scale-out that the Pi Cluster has, I went with 2 CPU cores per VM for the numbers above.
• I also had to adjust VirtualBox to give 1.5 GB of RAM per VM, instead of 1 GB like the Pis, because the VMs are running 64-bit Debian and have a little more memory headroom as a result. There was a ton of swapping on the master node (kube1) if I just stuck with 1024 MB / 1 GB.

[geerlingguy]

Updated my slides; still need to update the Drupal Benchmarks page on the site though.

[geerlingguy]

Updated, pushing the new container version up to the live site now.