Make HTTP no slower than Foolscap for mutable uploads and downloads #3957
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#3957
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
It seems like the fix for #3954 mostly helps with this, but I am having hard time testing larger files due to #3956, so need to wait until that's fixed to do more testing.
For a tens-of-MB mutable SDMF upload, with no network latency, HTTP upload is about twice as slow as Foolscap. Downloads are slower, but not as much. The issue seems to mostly be CPU.
With network latency of 60ms, the difference between HTTP and Foolscap becomes less marked. The latency penalty is not terrible.
Conclusion: As a first pass, for SDMF figure out why HTTP is using more CPU.
Looking at profiling results. 10-15% of CPU time is at least CDDL validation and CBOR decoding. And there's some HTTP parsing. So that's probably a big part of it.
My first attempt to speed up CDDL validation was a failure. As a short-term solution (and probably a good idea anyway) I'm going to move CDDL validation and CBOR parsing into a thread, so at least it doesn't block the event loop (or block it as much). CDDL validation is the bulk of the time at the moment (which is embarassing, but OK) and it will release the GIL. This won't improve latency, but it will help server parallelism: #3968