diff --git a/slides/common/composedown.md b/slides/common/composedown.md new file mode 100644 index 00000000..5fc6b8ff --- /dev/null +++ b/slides/common/composedown.md @@ -0,0 +1,12 @@ +## Clean up + +- Before moving on, let's remove those containers + +.exercise[ + +- Tell Compose to remove everything: + ```bash + docker-compose down + ``` + +] diff --git a/slides/common/composescale.md b/slides/common/composescale.md new file mode 100644 index 00000000..f816ca31 --- /dev/null +++ b/slides/common/composescale.md @@ -0,0 +1,169 @@ +## Scaling up the application + +- Our goal is to make that performance graph go up (without changing a line of code!) + +-- + +- Before trying to scale the application, we'll figure out if we need more resources + + (CPU, RAM...) + +- For that, we will use good old UNIX tools on our Docker node + +--- + +## Looking at resource usage + +- Let's look at CPU, memory, and I/O usage + +.exercise[ + +- run `top` to see CPU and memory usage (you should see idle cycles) + + + +- run `vmstat 1` to see I/O usage (si/so/bi/bo) +
(the 4 numbers should be almost zero, except `bo` for logging) + + + +] + +We have available resources. + +- Why? +- How can we use them? + +--- + +## Scaling workers on a single node + +- Docker Compose supports scaling +- Let's scale `worker` and see what happens! + +.exercise[ + +- Start one more `worker` container: + ```bash + docker-compose scale worker=2 + ``` + +- Look at the performance graph (it should show a x2 improvement) + +- Look at the aggregated logs of our containers (`worker_2` should show up) + +- Look at the impact on CPU load with e.g. top (it should be negligible) + +] + +--- + +## Adding more workers + +- Great, let's add more workers and call it a day, then! + +.exercise[ + +- Start eight more `worker` containers: + ```bash + docker-compose scale worker=10 + ``` + +- Look at the performance graph: does it show a x10 improvement? + +- Look at the aggregated logs of our containers + +- Look at the impact on CPU load and memory usage + +] + +--- + +# Identifying bottlenecks + +- You should have seen a 3x speed bump (not 10x) + +- Adding workers didn't result in linear improvement + +- *Something else* is slowing us down + +-- + +- ... But what? + +-- + +- The code doesn't have instrumentation + +- Let's use state-of-the-art HTTP performance analysis! +
(i.e. good old tools like `ab`, `httping`...) + +--- + +## Accessing internal services + +- `rng` and `hasher` are exposed on ports 8001 and 8002 + +- This is declared in the Compose file: + + ```yaml + ... + rng: + build: rng + ports: + - "8001:80" + + hasher: + build: hasher + ports: + - "8002:80" + ... + ``` + +--- + +## Measuring latency under load + +We will use `httping`. + +.exercise[ + +- Check the latency of `rng`: + ```bash + httping -c 3 localhost:8001 + ``` + +- Check the latency of `hasher`: + ```bash + httping -c 3 localhost:8002 + ``` + +] + +`rng` has a much higher latency than `hasher`. + +--- + +## Let's draw hasty conclusions + +- The bottleneck seems to be `rng` + +- *What if* we don't have enough entropy and can't generate enough random numbers? + +- We need to scale out the `rng` service on multiple machines! + +Note: this is a fiction! We have enough entropy. But we need a pretext to scale out. + +(In fact, the code of `rng` uses `/dev/urandom`, which never runs out of entropy... +
+...and is [just as good as `/dev/random`](http://www.slideshare.net/PacSecJP/filippo-plain-simple-reality-of-entropy).) diff --git a/slides/common/sampleapp.md b/slides/common/sampleapp.md index c470e887..13147a3b 100644 --- a/slides/common/sampleapp.md +++ b/slides/common/sampleapp.md @@ -340,189 +340,3 @@ class: extra-details - Jérôme is clearly incapable of writing good frontend code ---- - -## Scaling up the application - -- Our goal is to make that performance graph go up (without changing a line of code!) - --- - -- Before trying to scale the application, we'll figure out if we need more resources - - (CPU, RAM...) - -- For that, we will use good old UNIX tools on our Docker node - ---- - -## Looking at resource usage - -- Let's look at CPU, memory, and I/O usage - -.exercise[ - -- run `top` to see CPU and memory usage (you should see idle cycles) - - - -- run `vmstat 1` to see I/O usage (si/so/bi/bo) -
(the 4 numbers should be almost zero, except `bo` for logging) - - - -] - -We have available resources. - -- Why? -- How can we use them? - ---- - -## Scaling workers on a single node - -- Docker Compose supports scaling -- Let's scale `worker` and see what happens! - -.exercise[ - -- Start one more `worker` container: - ```bash - docker-compose scale worker=2 - ``` - -- Look at the performance graph (it should show a x2 improvement) - -- Look at the aggregated logs of our containers (`worker_2` should show up) - -- Look at the impact on CPU load with e.g. top (it should be negligible) - -] - ---- - -## Adding more workers - -- Great, let's add more workers and call it a day, then! - -.exercise[ - -- Start eight more `worker` containers: - ```bash - docker-compose scale worker=10 - ``` - -- Look at the performance graph: does it show a x10 improvement? - -- Look at the aggregated logs of our containers - -- Look at the impact on CPU load and memory usage - -] - ---- - -# Identifying bottlenecks - -- You should have seen a 3x speed bump (not 10x) - -- Adding workers didn't result in linear improvement - -- *Something else* is slowing us down - --- - -- ... But what? - --- - -- The code doesn't have instrumentation - -- Let's use state-of-the-art HTTP performance analysis! -
(i.e. good old tools like `ab`, `httping`...) - ---- - -## Accessing internal services - -- `rng` and `hasher` are exposed on ports 8001 and 8002 - -- This is declared in the Compose file: - - ```yaml - ... - rng: - build: rng - ports: - - "8001:80" - - hasher: - build: hasher - ports: - - "8002:80" - ... - ``` - ---- - -## Measuring latency under load - -We will use `httping`. - -.exercise[ - -- Check the latency of `rng`: - ```bash - httping -c 3 localhost:8001 - ``` - -- Check the latency of `hasher`: - ```bash - httping -c 3 localhost:8002 - ``` - -] - -`rng` has a much higher latency than `hasher`. - ---- - -## Let's draw hasty conclusions - -- The bottleneck seems to be `rng` - -- *What if* we don't have enough entropy and can't generate enough random numbers? - -- We need to scale out the `rng` service on multiple machines! - -Note: this is a fiction! We have enough entropy. But we need a pretext to scale out. - -(In fact, the code of `rng` uses `/dev/urandom`, which never runs out of entropy... -
-...and is [just as good as `/dev/random`](http://www.slideshare.net/PacSecJP/filippo-plain-simple-reality-of-entropy).) - ---- - -## Clean up - -- Before moving on, let's remove those containers - -.exercise[ - -- Tell Compose to remove everything: - ```bash - docker-compose down - ``` - -] diff --git a/slides/kube-halfday.yml b/slides/kube-halfday.yml index cfdcc4b4..878124f7 100644 --- a/slides/kube-halfday.yml +++ b/slides/kube-halfday.yml @@ -17,6 +17,8 @@ chapters: - - common/prereqs.md - kube/versions-k8s.md - common/sampleapp.md + - common/composescale.md + - common/composedown.md - - kube/concepts-k8s.md - common/declarative.md - kube/declarative.md diff --git a/slides/kube-selfpaced.yml b/slides/kube-selfpaced.yml index 11b0c0e5..cb077a8d 100644 --- a/slides/kube-selfpaced.yml +++ b/slides/kube-selfpaced.yml @@ -17,6 +17,8 @@ chapters: - - common/prereqs.md - kube/versions-k8s.md - common/sampleapp.md + - common/composescale.md + - common/composedown.md - - kube/concepts-k8s.md - common/declarative.md - kube/declarative.md diff --git a/slides/swarm-fullday.yml b/slides/swarm-fullday.yml index f2a85f1c..2d273bd0 100644 --- a/slides/swarm-fullday.yml +++ b/slides/swarm-fullday.yml @@ -22,6 +22,8 @@ chapters: - - common/prereqs.md - swarm/versions.md - common/sampleapp.md + - common/composescale.md + - common/composedown.md - swarm/swarmkit.md - common/declarative.md - swarm/swarmmode.md diff --git a/slides/swarm-halfday.yml b/slides/swarm-halfday.yml index 096cc000..c1c23575 100644 --- a/slides/swarm-halfday.yml +++ b/slides/swarm-halfday.yml @@ -22,6 +22,8 @@ chapters: - - common/prereqs.md - swarm/versions.md - common/sampleapp.md + - common/composescale.md + - common/composedown.md - swarm/swarmkit.md - common/declarative.md - swarm/swarmmode.md diff --git a/slides/swarm-selfpaced.yml b/slides/swarm-selfpaced.yml index 7fe2a40f..f78de79c 100644 --- a/slides/swarm-selfpaced.yml +++ b/slides/swarm-selfpaced.yml @@ -23,6 +23,8 @@ chapters: Part 1 - common/sampleapp.md + - common/composescale.md + - common/composedown.md - swarm/swarmkit.md - common/declarative.md - swarm/swarmmode.md diff --git a/slides/swarm-video.yml b/slides/swarm-video.yml index a11761e2..47deb73c 100644 --- a/slides/swarm-video.yml +++ b/slides/swarm-video.yml @@ -23,6 +23,8 @@ chapters: Part 1 - common/sampleapp.md + - common/composescale.md + - common/composedown.md - swarm/swarmkit.md - common/declarative.md - swarm/swarmmode.md