DataAccessPerformance
DataAccessPerformance copied to clipboard
Meeting notes 1/22/2018
Attendees: @ajcvickers @anpete @halter73, @roji @sebastienros @divega
Today @halter73 gave us a great introduction on the history and future of optimizing Kestrel and how some of the same ideas could apply to data access.
A few topics we touched on:
- Usage of managed sockets
- Important to reuse handlers (probably already happening with the awaitable we use in Peregrine)
- Use new Memory APIs in 2.1: we learned about a few reasons this might perform better that managing the buffers ourselves
- Is managed sockets improving further in the long termp?
- Usage of pipelines
- Simple and efficient programming model for managing buffers with async
- There are a few reasons we may want to look at it (e.g. for both Peregrine and Npgsql) even if we feel that the custom code we use right now is ok
- Usage of libuv
- Currently more efficient than managed sockets for Kestrel, but it is a goal to close the gap
- We don't know how much it would impact to use it for data access and this is something we want to experiment with
- Usage of new APIs in 2.1
- This applies to System.Memory, and the new sockets APIs as well as pipelines
- We think it would be ok to cross-compile to take advantage of these if there is significant perf gain