streams: add cork option to pipe #2020

calvinmetcalf · 2015-06-19T17:09:16Z

Adds an option to .pipe to cork it before each write and
then uncork it next tick, based on discussion at
nodejs/readable-stream#145

chrisdickinson · 2015-06-19T17:22:59Z

Curious: why not just call cork on the destination stream to start with? Then the highwatermark handling will take care of subsequent writev flushing?

trevnorris · 2015-06-19T17:26:47Z

cork knows about the high water mark? There's something I must be misunderstanding.

mscdex · 2015-06-19T17:35:40Z

doc/api/stream.markdown

@@ -333,6 +333,8 @@ readable.isPaused() // === false
 * `destination` {[Writable][] Stream} The destination for writing data
 * `options` {Object} Pipe options
  * `end` {Boolean} End the writer when the reader ends. Default = `true`
+  * `cork` {Boolean} Before each write cork the stream and then uncork it on the


there should probably be a comma after Before each write

calvinmetcalf · 2015-06-19T17:36:57Z

@chrisdickinson because then you have to wait until you hit the highwatermark before you actually write anything, see the comment by @indutny in the readable stream issue

mscdex · 2015-06-19T17:37:49Z

lib/_stream_readable.js

+    debug('corking');
+    corked = true;
+    dest.cork();
+    process.nextTick(function () {


I wonder if pulling this anonymous function out of maybeCork() would help performance-wise?

chrisdickinson · 2015-06-19T17:44:43Z

OK, I was wrong – cork and uncork have no idea about highwatermark. That said, I'm not sure I'm fully on board with this change (though I may be misunderstanding it.)

So, to check my assumptions about how streams work (and in particular, how net.Streams work):

First tick of the event loop.
1. We write once to the net.Socket. It immediately tries to flush to the underlying TCPWrap.
2. We write again to the net.Socket, N times. These all buffer, while the first write finishes.
First write completes.
1. We flush all buffered writes to the TCPWrap using _writev.
2. All writes that happen while this large buffer flushes are themselves buffered, until HWM.

Right now streams will be flushing chunks without using cork, uncork. The only write that is guaranteed to escape that is the first write. The size of the outgoing packet is determined by the amount of data that the source stream can generate during packet flushes.

Adds an option to .pipe to cork it before each write and then uncork it next tick, based on discussion at nodejs/readable-stream#145

chrisdickinson · 2015-06-19T18:08:10Z

Things that could cause my assumptions to be incorrect:

nodelay TCPWrap writes could be synchronous (I don't know if they are for sure, but some initial research seems to point to "they're async.")
the importance of batching writes for large packets is higher than I assume (that is to say, we want to collect more than "amount of data the source can generate during a flush" bytes before flushing.)

These both seem like TCP-specific concerns – it might be better to solve them at the net.Socket level than at the stream.Writable level.

calvinmetcalf · 2015-06-19T18:25:09Z

the importance of batching writes for large packets is higher than I assume (that is to say, we want to collect more than "amount of data the source can generate during a flush" bytes before flushing.)

This is the more general benefit that could apply to other streams that want to strike a balance between per write overhead and latency

trevnorris · 2015-06-19T18:35:31Z

Just for reference, this is basically the same thing the http module does today.

trevnorris · 2015-06-19T18:39:28Z

Another key component in this is the interaction with uv_try_write. You want to immediately write out as much as the kernel can handle then queue the remaining. It's not uncommon that all writes can be done immediately. This affects all uv_stream_t instances.

calvinmetcalf · 2015-06-19T18:44:29Z

@mscdex updated based on your suggestions

indutny · 2015-06-19T20:24:44Z

@trevnorris still it is faster to do just one writev call than multiple ones.

trevnorris · 2015-06-19T20:34:22Z

@indutny internally doesn't it automatically write out as much as possible using uv_try_write before setting up the WriteReq?

indutny · 2015-06-19T20:35:12Z

Yes, but it will pass multiple buffers as a single input with writev.

trevnorris · 2015-06-19T20:58:52Z

Sure, but uv_try_write only takes one at a time. That's what I was trying to get at above. Thought it may be a performance advantage to write immediately until uv_try_write fails, then queue up the remaining for writev. Simply because between the first set of running uv_try_write the kernel may have flushed some of the data and could accept more when writev ran.

But the timing could also be so minimal that it doesn't really matter.

indutny · 2015-06-19T21:01:37Z

Not really, it takes multiple:

UV_EXTERN int uv_try_write(uv_stream_t* handle,
                           const uv_buf_t bufs[],
                           unsigned int nbufs);

indutny · 2015-06-19T21:02:51Z

Though, your comments are quite correct. I am not suggesting this should be a default behavior in any way. But for my use case it would be beneficial to introduce this option, otherwise I will need to concatenate the buffers manually in memory.

trevnorris · 2015-06-19T21:07:22Z

Doh. Memory failure. Thanks for correcting me.

My comment was more just an observation I realized while looking over this PR. Definitely not something I think should be introduced in this PR. :-)

chrisdickinson · 2015-06-20T00:09:06Z

@calvinmetcalf:

This is the more general benefit that could apply to other streams that want to strike a balance between per write overhead and latency

We're talking about bringing back lowWatermark?

@indutny:

Based on this comment, it seems like you should be seeing at least one writev of size N>1. Is the problem that:

you are not seeing any writev of size N>1 happen, or
the writev calls you are seeing are all of N<desired-size, or
the initial writev call is of size N==1?

indutny · 2015-06-21T01:04:11Z

@chrisdickinson they can't happen because I am piping to the socket, not writing to it myself. So every write results in separate write() syscall, unless some of them will fail to complete immediately and will result in buffering (which is rare in the most setups I am using).

ronkorving · 2015-07-11T07:58:46Z

I have a use-case where I'm piping from a _transform to a writable, and would benefit from the same solution. For me however, nextTick would be overkill (not sure what the cost of a nexttick is tbh), as _transform already uses a callback to denote the end of a batch of writes. Perhaps the transform use case could be optimized?

ronkorving · 2015-07-11T07:59:49Z

lib/_stream_readable.js

@@ -515,9 +518,26 @@ Readable.prototype.pipe = function(dest, pipeOpts) {
      ondrain();
  }

+  function maybeCork() {
+    if (!autoCork || corked) {
+      debug('already corked');


Not technically correct in the case of autoCork being false.

True should be more like, 'no need to cork'

ronkorving · 2015-07-12T07:03:34Z

I just submitted #2167 which I think might really benefit from this.

brendanashworth · 2015-08-31T07:06:49Z

lib/_stream_readable.js

@@ -467,6 +467,9 @@ Readable.prototype.pipe = function(dest, pipeOpts) {
              dest !== process.stdout &&
              dest !== process.stderr;

+  var autoCork = pipeOpts && pipeOpts.cork && (typeof dest.cork === 'function');


Is there a time when dest.cork isn't a function? Won't it error anyways if it isn't a writable stream?

Old streams?

Ah, that makes sense! Thanks!

jasnell · 2015-11-16T04:41:14Z

@calvinmetcalf ... ping ... is this still something you'd like to pursue?

calvinmetcalf · 2015-11-16T10:40:53Z

sure I can rebase

calvinmetcalf · 2016-03-04T16:32:13Z

closing this as I'm not so sure we need this

calvinmetcalf mentioned this pull request Jun 19, 2015

cork()/uncork() and pipe() nodejs/readable-stream#145

Closed

mscdex added the stream Issues and PRs related to the stream subsystem. label Jun 19, 2015

mscdex reviewed Jun 19, 2015
View reviewed changes

streams: add cork option to pipe

25b8da1

Adds an option to .pipe to cork it before each write and then uncork it next tick, based on discussion at nodejs/readable-stream#145

calvinmetcalf force-pushed the pipe-cork branch from 8a1f6c1 to 25b8da1 Compare June 19, 2015 17:58

rvagg force-pushed the master branch from 9d21135 to 628a3ab Compare June 25, 2015 09:18

ronkorving reviewed Jul 11, 2015
View reviewed changes

indutny force-pushed the master branch from bffb204 to eb35968 Compare July 22, 2015 21:21

brendanashworth reviewed Aug 31, 2015
View reviewed changes

brendanashworth added the semver-minor PRs that contain new features and should be released in the next minor version. label Sep 1, 2015

rvagg force-pushed the master branch from 11c25c2 to ba02bd0 Compare September 6, 2015 11:55

jasnell added the stalled Issues and PRs that are stalled. label Nov 16, 2015

Trott force-pushed the master branch from 1e896a6 to 082cc8d Compare December 27, 2015 02:00

calvinmetcalf closed this Mar 4, 2016

brendanashworth mentioned this pull request Aug 3, 2016

http: optimize by corking outgoing requests #7946

Closed

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

streams: add cork option to pipe #2020

streams: add cork option to pipe #2020

calvinmetcalf commented Jun 19, 2015

chrisdickinson commented Jun 19, 2015

trevnorris commented Jun 19, 2015

mscdex Jun 19, 2015

calvinmetcalf commented Jun 19, 2015

mscdex Jun 19, 2015

chrisdickinson commented Jun 19, 2015

chrisdickinson commented Jun 19, 2015

calvinmetcalf commented Jun 19, 2015

trevnorris commented Jun 19, 2015

trevnorris commented Jun 19, 2015

calvinmetcalf commented Jun 19, 2015

indutny commented Jun 19, 2015

trevnorris commented Jun 19, 2015

indutny commented Jun 19, 2015

trevnorris commented Jun 19, 2015

indutny commented Jun 19, 2015

indutny commented Jun 19, 2015

trevnorris commented Jun 19, 2015

chrisdickinson commented Jun 20, 2015

indutny commented Jun 21, 2015

ronkorving commented Jul 11, 2015

ronkorving Jul 11, 2015

calvinmetcalf Jul 11, 2015

ronkorving commented Jul 12, 2015

brendanashworth Aug 31, 2015

indutny Aug 31, 2015

brendanashworth Aug 31, 2015

jasnell commented Nov 16, 2015

calvinmetcalf commented Nov 16, 2015

calvinmetcalf commented Mar 4, 2016

streams: add cork option to pipe #2020

streams: add cork option to pipe #2020

Conversation

calvinmetcalf commented Jun 19, 2015

chrisdickinson commented Jun 19, 2015

trevnorris commented Jun 19, 2015

mscdex Jun 19, 2015

Choose a reason for hiding this comment

calvinmetcalf commented Jun 19, 2015

mscdex Jun 19, 2015

Choose a reason for hiding this comment

chrisdickinson commented Jun 19, 2015

chrisdickinson commented Jun 19, 2015

calvinmetcalf commented Jun 19, 2015

trevnorris commented Jun 19, 2015

trevnorris commented Jun 19, 2015

calvinmetcalf commented Jun 19, 2015

indutny commented Jun 19, 2015

trevnorris commented Jun 19, 2015

indutny commented Jun 19, 2015

trevnorris commented Jun 19, 2015

indutny commented Jun 19, 2015

indutny commented Jun 19, 2015

trevnorris commented Jun 19, 2015

chrisdickinson commented Jun 20, 2015

indutny commented Jun 21, 2015

ronkorving commented Jul 11, 2015

ronkorving Jul 11, 2015

Choose a reason for hiding this comment

calvinmetcalf Jul 11, 2015

Choose a reason for hiding this comment

ronkorving commented Jul 12, 2015

brendanashworth Aug 31, 2015

Choose a reason for hiding this comment

indutny Aug 31, 2015

Choose a reason for hiding this comment

brendanashworth Aug 31, 2015

Choose a reason for hiding this comment

jasnell commented Nov 16, 2015

calvinmetcalf commented Nov 16, 2015

calvinmetcalf commented Mar 4, 2016