DataAccessPerformance
DataAccessPerformance copied to clipboard
Meeting notes 1/30/2018
Attendees: @roji @ajcvickers @anpete @sebastienros @divega @davidfowl @DamianEdwards @mikeharder
Npgsql improvements on Fortunes for physical hardware on Linux:
60,000 rps - Npgsql Latest released 77,000 rps - Npgsql New release 97,000 rps - Npgsql latest experimental changes 117,000 rps - Peregrine 119,000 rps - Undertow (Java)
TO-DO:
- Windows
- Cloud
Improvements to Npgsql: Connection pool contention optimization (@roji to file issues on possible improvements for ASP.NET Core pooling code) Removal of Task<T> allocations Prepared statements written directly to buffer (still pending)
Possible improvements for ADO.NET
- API Connection pooling could be made explicit (expose a connection pool) to avoid the lookup and the allocation of the user facing connection
- Explicit prepared commands that allows reusing commands definitions
- Prepare (as well as other APIs) needs to be async
- Reader pooling
- Update
- Ability to write parameters without boxing (Npgsql has a non ADO.NET API for it)
- Other update performance such as batching
Possible improvements for EF Core:
- Consider batching for query
Long term goals
- Apply same optimizations to other ADO.NET providers
- We can experiment with pipelines, but later would be better (could help with SSL)