Optimize request/response API together with a modernized internal engine #767
Description
The integration of additional engines showed, that we should change the API design of the core types IRequest and IResponse to improve performance and work being done by the engines. In addition to this, there are lots of improvements which should be implemented by the internal engine, most probably via a new parser.
The following sections describe the key changes to get a picture of how the API may look like.
Memory Friendly API
Requests are basically a chunk of memory read from the underlying connection. All work required to transform this memory is expensive. Therefore, our API needs to find a good balance between user comfort and transformation work. As an example, the routing currently creates several objects from the requested path, which is basically just a few bytes in memory.
This change may involve:
- Reducing the interface of the API, e.g. no dictionary properties for headers but methods such as
GetHeader() : string? - Providing access to the underlying memory to handlers so they can implement a more efficient solution if needed (e.g.
GetHeaderRaw() : IReadOnlyMemory) - Considering to implement comfort functions (such as the
GetHeader()above) as extensions to a minimalistic core, reducing the code required from adapters and engines - Reworking core types such as
FlexibleContentType
Embracing PipeWriter / PipeReader
Use those types for reading and writing, with streams only as syntactic sugar on top. This includes:
- Clarification how content wrapping (e.g. chunked encoding, compression) will work
- Whether body buffering is still a requirement
Reducing async where applicable
Asynchronous methods involve an overhead (as soon as async keyword is used). As we only need this to read and write data, we should reduce the usage to a minimum. For example, the request parser should be synchronous.