You're misunderstanding. I'm talking about connection pools. If you want to avoid a new connection for every stream, you might use a connection pool. But getting a connection out of the pool may not be a synchronous action. If all connections are in use, you may have to wait. Thus you would need an async "createConnection" method.
And no one else can tell you what "too expensive" means for your app. If you're asking if creating connections constantly is more expensive then not creating connections constantly, then the answer is yes :) But it looks like you can reuse the redis stream object indefinitely, so I'm not sure you'd need to keep creating these. If you're asking how expensive is it to keep creating connections, that depends on the usage patterns of your app. IMO not expensive enough to worry about, until it becomes a problem. :Marco On Sun, Sep 16, 2012 at 8:41 PM, Mike Nichols <[email protected]>wrote: > Looking into this more, I think this won't be a problem with holding > resources or async connect. When you call net.createConnection the .connect > is called right away on the underlying Socket. When you do a write to the > connection that was created it will connect and buffer the writes until it > is connected; ie, when using .pipe. This could be a bottleneck, but maybe > is negligible. > > When the stream being piped into the connection is ended, then the > connection is disposed (I assume). If any of this is wrong I'd like to be > corrected. > > Still, this doesn't answer whether creating a connection each time is too > expensive, or whether I should cache connections for reuse. > > > > On Sunday, September 16, 2012 9:09:58 PM UTC-5, Marco Rogers wrote: > >> You can definitely get into trouble if you plan to create lots of these >> steam objects. node_redis and other libs use a connection pool underneath >> so you don't overuse resources. Of course that means `createConnection` >> would need to be async here, because you may have to wait for an available >> connection from the pool. But keep in mind you're right that it "could" be >> inefficient. But it's better to validate your assumptions with testing for >> your particular use cases. >> >> :Marco >> >> On Sun, Sep 16, 2012 at 6:35 PM, Mike Nichols <[email protected]>wrote: >> >>> Here is the code under consideration (from redis-stream module) which I >>> am considering using. >>> Writing to the underlying stream creates a new connection. It seems like >>> this would be expensive, but that is what I am asking...whether it is or >>> not. One might say to keep the stream open with {end:false} but that isn't >>> suitable often since the args change to consume the wrapping code. I think >>> I would have cached the connection the first time, but I am not sure if >>> that is important or not in node using the Net lib. >>> >>> Redis.prototype.stream = function (cmd, key, curry /* moar? */) { >>> var curry = Array.prototype.slice.call(**arguments) >>> , clip = 1 >>> , _redis = this.createConnection() >>> , stream = es.pipe( >>> es.pipe( >>> es.map(function (data, fn) { >>> var elems = [].concat(stream.curry) >>> , str = data+'' >>> if (!str.length) return fn() >>> else elems.push(str) >>> // console.log('write', str) >>> return Redis.parse(elems, fn) >>> }), >>> _redis >>> ), >>> es.pipe( >>> es.split('\r\n'), >>> es.map(replyParser) >>> ) >>> ) >>> ; >>> stream.curry = curry >>> stream.redis = _redis >>> stream.redis.write(Redis.**parse([ 'select', this.db ])) >>> return stream >>> >>> >>> On Sunday, September 16, 2012 7:45:46 PM UTC-5, Marco Rogers wrote: >>>> >>>> It depends on the module and what it's doing. Can you point to it and >>>> give some more info about your use case? >>>> >>>> :Marco >>>> >>>> On Sunday, September 16, 2012 1:59:02 PM UTC-7, Mike Nichols wrote: >>>>> >>>>> I am using a module which uses a net.createConnection (for redis) per >>>>> stream instance. This would seem like it is not so efficient and should >>>>> instead hold on to the same connection and use that for each new instance >>>>> of the stream. >>>>> >>>>> Is it 'safe' to hold onto the connection created for indefinite amount >>>>> of time? I have looked around and haven't been able to find guidance on >>>>> this. I noted that socket.io is doing some kind of persistence >>>>> connections but wasn't sure if I should follow suit. >>>>> >>>>> Any pointers or redirects to info is appreciated. >>>>> >>>>> Thanks! >>>>> Mike >>>>> >>>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-* >>> *Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines> >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> >>> To unsubscribe from this group, send email to >>> nodejs+un...@**googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en> >>> >> >> >> >> -- >> Marco Rogers >> [email protected] | https://twitter.com/polotek >> >> >> Life is ten percent what happens to you and ninety percent how you >> respond to it. >> - Lou Holtz >> > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Marco Rogers [email protected] | https://twitter.com/polotek Life is ten percent what happens to you and ninety percent how you respond to it. - Lou Holtz -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
