To be honest, I’ve been putting off benchmarking the ktor (https://ktor.io) and http4k (https://http4k.org) libraries, because measuring software performance is hard, and I’m not sure that it makes good TV.

The last time I tried, I ended up seeing errors where connections were being broken or reset if we tried to make requests too fast. We can hardly compare performance of things that aren’t working, so this episode I’m having to do science on the code to work out what is causing the problem.

Once the problem is isolated (thanks for your help Albert) I realised that I had to change the approach to measurement. Instead of making requests as fast as possible, I changed the tests to adaptively vary the rate to find the maximum we can sustain without errors.

I was trained as a physicist, where experiment design is part of the culture, so I hope this episode gives an insight into the thought processes involved in diagnosing and fixing problems in code that we don’t own.

In this episode

* 00:01:00 Reviewing our current measurements
* 00:02:11 We are making all our requests as fast as possible
* 00:03:43 Running the tests
* 00:04:13 Hypothesis
* 00:05:27 What about sustained throughput?
* 00:06:17 Making more (simultaneous) requests leads to a different error
* 00:06:56 AI for explaining errors
* 00:07:59 Devise an experiment to collect evidence
* 00:09:04 Hypothesis - throttling the requests will fix the errors
* 00:10:39 Analysing the results
* 00:11:11 Now refactor to adaptive throttling
* 00:14:20 We've now broken our sustained rate - more refactoring
* 00:17:19 Now each batch is the same duration, with more or fewer requests
* 00:18:19 That once again prompts our open files error
* 00:18:58 That will do for now
* 00:19:14 Stop the press!

The code for this video is on a GitHub fork https://github.com/dmcg/ktor-document...

Other videos on proxies can be found in a Reflection playlist    • Reflection  

This video is in a playlist of Ktor episodes (   • Ktor  ) and http4k (   • http4k  )

If you like this video, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (http://java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style.