Non-blocking IO for the masses (WebEngDUS)

Non-blocking IO for the masses (WebEngDUS)

I/O is everywhere. I/O is slow. There's no denying it. Using traditional blocking I/O calls can thus be seen as a huge contributor to slow applications. This talk discusses how non-blocking I/O can help in building high performance, event-driven, reactive, concurrent, single-threaded applications (bingo). Don't worry, no need to install Node.js and npm install half the internet. Let's build high-performance applications from scratch with whatever language you're most comfortable with!

---

This talk was presented at WebEngDUS (https://www.meetup.com/de-DE/Web-Engineering-Duesseldorf/events/252097938/) as one of three talks this day (~20 min each). This implies that this is only supposed to be a 101 introduction.

You can find the examples (source code) here: https://gist.github.com/clue/e0425c34c0ab13e8496716aae0219245

D1b6700884ac0ae368918ad171bb6a75?s=128

Christian Lück

July 12, 2018
Tweet

Transcript

  1. 2.

    Agenda - Hello! - 101 of non-blocking I/O - Examples

    from scratch - Putting into practice - Conclusions 2
  2. 14.

    Who are you? 14 now that you know me… -

    programmers / developers? - architects / engineers?
  3. 18.
  4. 25.

    I/O is everywhere third party HTTP APIs (RESTful, SOAP, you

    name it…) mysql, postgres filesystem I/O (session files) 25
  5. 26.

    I/O is everywhere third party HTTP APIs (RESTful, SOAP, you

    name it…) mysql, postgres filesystem I/O (session files) redis, memcache 26
  6. 41.
  7. 43.
  8. 48.

    48

  9. 53.

    53

  10. 54.

    54

  11. 61.

    61

  12. 64.

    5k requests/s 64 this is a local single core benchmark!

    dual core i3 => 10k requests/s 36M requests/h
  13. 68.
  14. 71.

    when? 71 app is I/O bound high(er) performance is wanted

    blocking and non-blocking can be separated
  15. 74.
  16. 85.
  17. 86.

    86

  18. 87.

    87