lukechilds/node - node - Gitea: Git with a cup of tea

10050 Commits

131 Branches

446 Tags

325 MiB

Tree: ea89fdfec4

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Ben Noordhuis	fda2b319dc	http: save roundtrips, convert buffers to strings This commit adds an optimization to the HTTP client that makes it possible to: * Pack the headers and the first chunk of the request body into a single write(). * Pack the chunk header and the chunk itself into a single write(). Because only one write() system call is issued instead of several, the chances of data ending up in a single TCP packet are phenomenally higher: the benchmark with `type=buf size=32` jumps from 50 req/s to 7,500 req/s, a 150-fold increase. This commit removes the check from `e4b716ef` that pushes binary encoded strings into the slow path. The commit log mentions that: We were assuming that any string can be concatenated safely to CRLF. However, for hex, base64, or binary encoded writes, this is not the case, and results in sending the incorrect response. For hex and base64 strings that's certainly true but binary strings are 'das Ding an sich': string.length is the same before and after decoding. Fixes #5528.	12 years ago

Ben Noordhuis

fda2b319dc

http: save roundtrips, convert buffers to strings

This commit adds an optimization to the HTTP client that makes it
possible to:

* Pack the headers and the first chunk of the request body into a
  single write().

* Pack the chunk header and the chunk itself into a single write().

Because only one write() system call is issued instead of several,
the chances of data ending up in a single TCP packet are phenomenally
higher: the benchmark with `type=buf size=32` jumps from 50 req/s to
7,500 req/s, a 150-fold increase.

This commit removes the check from e4b716ef that pushes binary encoded
strings into the slow path. The commit log mentions that:

    We were assuming that any string can be concatenated safely to
    CRLF.  However, for hex, base64, or binary encoded writes, this
    is not the case, and results in sending the incorrect response.

For hex and base64 strings that's certainly true but binary strings
are 'das Ding an sich': string.length is the same before and after
decoding.

Fixes #5528.

12 years ago

1 Commits (ea89fdfec4f7a6ff180149a5eacc3c7d84b87e39)