Writing high performance applications on Windows has been an 'open secret' for long time. Good free presentation I know of are Rick Vicik ones: - https://blo

Writing high performance applications on Windows has been an 'open secret' for long time. Good free presentation I know of are Rick Vicik ones: - https://blogs.technet.microsoft.com/winserverperformance/2008/04/25/designing-applications-for-high-performance-part-1/ - https://blogs.technet.microsoft.com/winserverperformance/2008/05/20/designing-applications-for-high-performance-part-ii/ - https://blogs.technet.microsoft.com/winserverperformance/2008/06/25/designing-applications-for-high-performance-part-iii-2/ A simplified explanation is that for good throughput one creates a completion port and binds a thread pool to it with as many threads as CPUs. Then all IO is done via the completion port. If the system is partitioned (NUMA) then one should create a completion port per node and partition the thread pool. I skip the details, read the links for a better explanation. The gist of it that the code written this way has no procedural flow when you read it. Instead of a sequence of function calls (read socket -> parse -> read file -> write socket), it must be a state machine which always reacts to some IO completion, modifies the state, posts some more IO and then returns the thread back to the pool (post socket read, socket read callback -> parse -> post file read, file read callback -> post socket write, write socket callback). Writing it as FSM makes it lot easier to understand. C# async/await is like a DSL that generates the FSM while you write fluent sequential code, easy to write and easy to read.