Consider usage of chi router as http framework for gateway #80
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-http-gw#80
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is your feature request related to a problem? Please describe.
Back in the days we chose fasthttp as a framework for our first gateway application, because it was blazing fast and provided non-buffered access to the payload, so we could transfer payload directly to the storage node (see the usage of RequestBodyStream).
Unfortunately, we can't use this framework in other gateways. Fasthttp does not provide convenient routing for large-scale S3 gateway and we use swagger-generated server for REST gateway.
Also it has some caveats e.g. a bit weird work with
RequestContext
without ability to cancel requestDescribe the solution you'd like
Not a while ago we supported chi router in the S3 gateway. Let's see if it provides some zero-buf options to work with payload and let's do some benchmarks.
To compare effectiveness of implementations with fasthttp and chi router, 2GB, 5GB and 10GB objects were uploaded. No significant difference was noticed.
There is a problem with headers handling: they transform (e.g. X-Attribute-FilePath → X-Attribute-Filepath) which doesn't allow to correctly set case sensitive attributes in object. Also, in implementation with chi router it wasn't possible to apply some of web settings.