container.training/slides/shared/composescale.md

Restarting in the background

• Many flags and commands of Compose are modeled after those of docker

.lab[

• Start the app in the background with the -d option:

  docker-compose up -d
  

• Check that our app is running with the ps command:

  docker-compose ps
  

]

docker-compose ps also shows the ports exposed by the application.

---

class: extra-details

Viewing logs

• The docker-compose logs command works like docker logs

.lab[

• View all logs since container creation and exit when done:

  docker-compose logs
  

• Stream container logs, starting at the last 10 lines for each container:

  docker-compose logs --tail 10 --follow
  

]

Tip: use ^S and ^Q to pause/resume log output.

---

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

.lab[

• 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!

.lab[

• Start one more worker container:

  docker-compose up -d --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!

.lab[

• Start eight more worker containers:

  docker-compose up -d --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:

    ...
    rng:
      build: rng
      ports:
      - "8001:80"
  
    hasher:
      build: hasher
      ports:
      - "8002:80"
    ...
  

---

Measuring latency under load

We will use httping.

.lab[

• Check the latency of rng:

  httping -c 3 localhost:8001
  

• Check the latency of hasher:

  httping -c 3 localhost:8002
  

]

rng has a much higher latency than hasher.