rtweed | 14 Oct 13:00 2010
Picon

Concurrency - Multiple database connections

I may just not have found what I'm looking for, but I haven't found
any readily available mechanism in the Node.js ecosystem for
distributing the load on a back-end database/store (eg Redis) across
multiple TCP sockets.  For example, I've only ever seen examples on
how to use fictorial's redis-node-client with a single socket.  I know
Redis is fast, but there must come a point when it (or some other
database connected in a similar way) just won't be able to keep up
with the queue of requests on the Node.js side via a single socket
connection.

So I'd be interested to know what work is being/has been done on TCP
socket pooling within Node.js to allow database load to be spread
across several threads.  Perhaps there's some examples I've missed?

[Of course databases with an HTTP interface aren't a problem since the
HTTP layer can do this work for me - so I'm thinking of simple TCP
socket interfaced databases, Redis being a good example of the genre]

Many thanks!

Arnout Kazemier | 14 Oct 13:03 2010

Re: Concurrency - Multiple database connections

Threads and multiple sockets are different things. If you want to connect to your database over multiple
sockets, i suggest you create a connection pool.
There are already a couple of modules that do this for you. Which should make it fairly easy to implement. 

On Oct 14, 2010, at 1:00 PM, rtweed wrote:

> I may just not have found what I'm looking for, but I haven't found
> any readily available mechanism in the Node.js ecosystem for
> distributing the load on a back-end database/store (eg Redis) across
> multiple TCP sockets.  For example, I've only ever seen examples on
> how to use fictorial's redis-node-client with a single socket.  I know
> Redis is fast, but there must come a point when it (or some other
> database connected in a similar way) just won't be able to keep up
> with the queue of requests on the Node.js side via a single socket
> connection.
> 
> So I'd be interested to know what work is being/has been done on TCP
> socket pooling within Node.js to allow database load to be spread
> across several threads.  Perhaps there's some examples I've missed?
> 
> [Of course databases with an HTTP interface aren't a problem since the
> HTTP layer can do this work for me - so I'm thinking of simple TCP
> socket interfaced databases, Redis being a good example of the genre]
> 
> Many thanks!
> 
> -- 
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs@...
> To unsubscribe from this group, send email to nodejs+unsubscribe@...
(Continue reading)

rtweed | 14 Oct 13:23 2010
Picon

Re: Concurrency - Multiple database connections

Yes I understand that and that's what I'm asking - how to create a
connection pool.  Which modules....and any examples of anyone using
them with, eg Redis?

On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
> Threads and multiple sockets are different things. If you want to connect to your database over multiple
sockets, i suggest you create a connection pool.
> There are already a couple of modules that do this for you. Which should make it fairly easy to implement.
>
> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>
>
>
> > I may just not have found what I'm looking for, but I haven't found
> > any readily available mechanism in the Node.js ecosystem for
> > distributing the load on a back-end database/store (eg Redis) across
> > multiple TCP sockets.  For example, I've only ever seen examples on
> > how to use fictorial's redis-node-client with a single socket.  I know
> > Redis is fast, but there must come a point when it (or some other
> > database connected in a similar way) just won't be able to keep up
> > with the queue of requests on the Node.js side via a single socket
> > connection.
>
> > So I'd be interested to know what work is being/has been done on TCP
> > socket pooling within Node.js to allow database load to be spread
> > across several threads.  Perhaps there's some examples I've missed?
>
> > [Of course databases with an HTTP interface aren't a problem since the
> > HTTP layer can do this work for me - so I'm thinking of simple TCP
> > socket interfaced databases, Redis being a good example of the genre]
(Continue reading)

Micheil Smith | 14 Oct 13:36 2010

Re: Re: Concurrency - Multiple database connections

Try looking into the internal module of FreeList, it may help you a little bit.

Yours,
Micheil Smith
--
BrandedCode.com

On 14/10/2010, at 10:23 PM, rtweed wrote:

> Yes I understand that and that's what I'm asking - how to create a
> connection pool.  Which modules....and any examples of anyone using
> them with, eg Redis?
> 
> 
> On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
>> Threads and multiple sockets are different things. If you want to connect to your database over multiple
sockets, i suggest you create a connection pool.
>> There are already a couple of modules that do this for you. Which should make it fairly easy to implement.
>> 
>> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>> 
>> 
>> 
>>> I may just not have found what I'm looking for, but I haven't found
>>> any readily available mechanism in the Node.js ecosystem for
>>> distributing the load on a back-end database/store (eg Redis) across
>>> multiple TCP sockets.  For example, I've only ever seen examples on
>>> how to use fictorial's redis-node-client with a single socket.  I know
>>> Redis is fast, but there must come a point when it (or some other
>>> database connected in a similar way) just won't be able to keep up
(Continue reading)

Arnout Kazemier | 14 Oct 13:48 2010

Re: Re: Concurrency - Multiple database connections

Here is something I use in my node-memcached driver; 

http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection.js#L107-164

implementation; http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L91-117

or: http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2e90cd80b019/lib/mc/pool.js

On Oct 14, 2010, at 1:23 PM, rtweed wrote:

> Yes I understand that and that's what I'm asking - how to create a
> connection pool.  Which modules....and any examples of anyone using
> them with, eg Redis?
> 
> 
> On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
>> Threads and multiple sockets are different things. If you want to connect to your database over multiple
sockets, i suggest you create a connection pool.
>> There are already a couple of modules that do this for you. Which should make it fairly easy to implement.
>> 
>> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>> 
>> 
>> 
>>> I may just not have found what I'm looking for, but I haven't found
>>> any readily available mechanism in the Node.js ecosystem for
>>> distributing the load on a back-end database/store (eg Redis) across
>>> multiple TCP sockets.  For example, I've only ever seen examples on
>>> how to use fictorial's redis-node-client with a single socket.  I know
>>> Redis is fast, but there must come a point when it (or some other
(Continue reading)

Tim Smart | 14 Oct 14:21 2010

Re: Re: Concurrency - Multiple database connections

Redis doesn't need multiple sockets really, as it pipelines requests. (If that was the database you were thinking about using)

Tim.

On 15 October 2010 00:48, Arnout Kazemier <info-Iak26U/GZYhWk0Htik3J/w@public.gmane.org> wrote:
Here is something I use in my node-memcached driver;

http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection.js#L107-164

implementation; http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L91-117

or: http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2e90cd80b019/lib/mc/pool.js


On Oct 14, 2010, at 1:23 PM, rtweed wrote:

> Yes I understand that and that's what I'm asking - how to create a
> connection pool.  Which modules....and any examples of anyone using
> them with, eg Redis?
>
>
> On 14 Oct, 12:03, Arnout Kazemier <i...-Iak26U/GZYhWk0Htik3J/w@public.gmane.org> wrote:
>> Threads and multiple sockets are different things. If you want to connect to your database over multiple sockets, i suggest you create a connection pool.
>> There are already a couple of modules that do this for you. Which should make it fairly easy to implement.
>>
>> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>>
>>
>>
>>> I may just not have found what I'm looking for, but I haven't found
>>> any readily available mechanism in the Node.js ecosystem for
>>> distributing the load on a back-end database/store (eg Redis) across
>>> multiple TCP sockets.  For example, I've only ever seen examples on
>>> how to use fictorial's redis-node-client with a single socket.  I know
>>> Redis is fast, but there must come a point when it (or some other
>>> database connected in a similar way) just won't be able to keep up
>>> with the queue of requests on the Node.js side via a single socket
>>> connection.
>>
>>> So I'd be interested to know what work is being/has been done on TCP
>>> socket pooling within Node.js to allow database load to be spread
>>> across several threads.  Perhaps there's some examples I've missed?
>>
>>> [Of course databases with an HTTP interface aren't a problem since the
>>> HTTP layer can do this work for me - so I'm thinking of simple TCP
>>> socket interfaced databases, Redis being a good example of the genre]
>>
>>> Many thanks!
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "nodejs" group.
>>> To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
>>> To unsubscribe from this group, send email to nodejs+unsubscribe-/JYPxA39Uh4Ykp1iOSErHA@public.gmane.orgm.
>>> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> To unsubscribe from this group, send email to nodejs+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To unsubscribe from this group, send email to nodejs+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.


--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
rtweed | 14 Oct 14:50 2010
Picon

Re: Concurrency - Multiple database connections

Thanks guys!

On 14 Oct, 13:21, Tim Smart <t...@...> wrote:
> Redis doesn't need multiple sockets really, as it pipelines requests. (If
> that was the database you were thinking about using)
>
> Tim.
>
> On 15 October 2010 00:48, Arnout Kazemier <i...@...> wrote:
>
>
>
> > Here is something I use in my node-memcached driver;
>
> >http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection....
>
> > implementation;
> >http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L...
>
> > or:
> >http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2...
>
> > On Oct 14, 2010, at 1:23 PM, rtweed wrote:
>
> > > Yes I understand that and that's what I'm asking - how to create a
> > > connection pool.  Which modules....and any examples of anyone using
> > > them with, eg Redis?
>
> > > On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
> > >> Threads and multiple sockets are different things. If you want to
> > connect to your database over multiple sockets, i suggest you create a
> > connection pool.
> > >> There are already a couple of modules that do this for you. Which should
> > make it fairly easy to implement.
>
> > >> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>
> > >>> I may just not have found what I'm looking for, but I haven't found
> > >>> any readily available mechanism in the Node.js ecosystem for
> > >>> distributing the load on a back-end database/store (eg Redis) across
> > >>> multiple TCP sockets.  For example, I've only ever seen examples on
> > >>> how to use fictorial's redis-node-client with a single socket.  I know
> > >>> Redis is fast, but there must come a point when it (or some other
> > >>> database connected in a similar way) just won't be able to keep up
> > >>> with the queue of requests on the Node.js side via a single socket
> > >>> connection.
>
> > >>> So I'd be interested to know what work is being/has been done on TCP
> > >>> socket pooling within Node.js to allow database load to be spread
> > >>> across several threads.  Perhaps there's some examples I've missed?
>
> > >>> [Of course databases with an HTTP interface aren't a problem since the
> > >>> HTTP layer can do this work for me - so I'm thinking of simple TCP
> > >>> socket interfaced databases, Redis being a good example of the genre]
>
> > >>> Many thanks!
>
> > >>> --
> > >>> You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > >>> To post to this group, send email to nodejs@...
> > >>> To unsubscribe from this group, send email to
> > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > .
> > >>> For more options, visit this group athttp://
> > groups.google.com/group/nodejs?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > > To post to this group, send email to nodejs@...
> > > To unsubscribe from this group, send email to
> > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nodejs@...
> > To unsubscribe from this group, send email to
> > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Mikeal Rogers | 14 Oct 19:31 2010
Picon

Re: Re: Concurrency - Multiple database connections

Keep in mind that not all databases are optimized for highly concurrent access.


Redis, CouchDB, and Postgres are optimized for high concurrency. MongoDB is optimized for very low numbers of concurrent connections.

It's a design decision so check in to what your database is better at before you go down the road of optimizing a client pool.

-Mikeal

On Thu, Oct 14, 2010 at 5:50 AM, rtweed <rob.tweed-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Thanks guys!

On 14 Oct, 13:21, Tim Smart <t... <at> fostle.com> wrote:
> Redis doesn't need multiple sockets really, as it pipelines requests. (If
> that was the database you were thinking about using)
>
> Tim.
>
> On 15 October 2010 00:48, Arnout Kazemier <i...-Iak26U/GZYhWk0Htik3J/w@public.gmane.org> wrote:
>
>
>
> > Here is something I use in my node-memcached driver;
>
> >http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection....
>
> > implementation;
> >http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L...
>
> > or:
> >http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2...
>
> > On Oct 14, 2010, at 1:23 PM, rtweed wrote:
>
> > > Yes I understand that and that's what I'm asking - how to create a
> > > connection pool.  Which modules....and any examples of anyone using
> > > them with, eg Redis?
>
> > > On 14 Oct, 12:03, Arnout Kazemier <i...-Iak26U/GZYhWk0Htik3J/w@public.gmane.org> wrote:
> > >> Threads and multiple sockets are different things. If you want to
> > connect to your database over multiple sockets, i suggest you create a
> > connection pool.
> > >> There are already a couple of modules that do this for you. Which should
> > make it fairly easy to implement.
>
> > >> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>
> > >>> I may just not have found what I'm looking for, but I haven't found
> > >>> any readily available mechanism in the Node.js ecosystem for
> > >>> distributing the load on a back-end database/store (eg Redis) across
> > >>> multiple TCP sockets.  For example, I've only ever seen examples on
> > >>> how to use fictorial's redis-node-client with a single socket.  I know
> > >>> Redis is fast, but there must come a point when it (or some other
> > >>> database connected in a similar way) just won't be able to keep up
> > >>> with the queue of requests on the Node.js side via a single socket
> > >>> connection.
>
> > >>> So I'd be interested to know what work is being/has been done on TCP
> > >>> socket pooling within Node.js to allow database load to be spread
> > >>> across several threads.  Perhaps there's some examples I've missed?
>
> > >>> [Of course databases with an HTTP interface aren't a problem since the
> > >>> HTTP layer can do this work for me - so I'm thinking of simple TCP
> > >>> socket interfaced databases, Redis being a good example of the genre]
>
> > >>> Many thanks!
>
> > >>> --
> > >>> You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > >>> To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> > >>> To unsubscribe from this group, send email to
> > nodejs+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<nodejs%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> > .
> > >>> For more options, visit this group athttp://
> > groups.google.com/group/nodejs?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > > To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> > > To unsubscribe from this group, send email to
> > nodejs+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<nodejs%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> > To unsubscribe from this group, send email to
> > nodejs+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<nodejs%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To unsubscribe from this group, send email to nodejs+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.


--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
rtweed | 14 Oct 19:37 2010
Picon

Re: Concurrency - Multiple database connections

Mikeal

Yep I'm OK on this for the databases I'm working with - GT.M and
Cache'

They can both support high numbers of concurrent connections, but on
the other hand their performance is such that most systems that access
them via Node.js won't need that many connections anyway.

Thanks

Rob

On 14 Oct, 18:31, Mikeal Rogers <mikeal.rog...@...> wrote:
> Keep in mind that not all databases are optimized for highly concurrent
> access.
>
> Redis, CouchDB, and Postgres are optimized for high concurrency. MongoDB is
> optimized for very low numbers of concurrent connections.
>
> It's a design decision so check in to what your database is better at before
> you go down the road of optimizing a client pool.
>
> -Mikeal
>
>
>
> On Thu, Oct 14, 2010 at 5:50 AM, rtweed <rob.tw...@...> wrote:
> > Thanks guys!
>
> > On 14 Oct, 13:21, Tim Smart <t...@...> wrote:
> > > Redis doesn't need multiple sockets really, as it pipelines requests. (If
> > > that was the database you were thinking about using)
>
> > > Tim.
>
> > > On 15 October 2010 00:48, Arnout Kazemier <i...@...> wrote:
>
> > > > Here is something I use in my node-memcached driver;
>
> > > >http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection..
> > ..
>
> > > > implementation;
> > > >http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L.
> > ..
>
> > > > or:
> > > >http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2.
> > ..
>
> > > > On Oct 14, 2010, at 1:23 PM, rtweed wrote:
>
> > > > > Yes I understand that and that's what I'm asking - how to create a
> > > > > connection pool.  Which modules....and any examples of anyone using
> > > > > them with, eg Redis?
>
> > > > > On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
> > > > >> Threads and multiple sockets are different things. If you want to
> > > > connect to your database over multiple sockets, i suggest you create a
> > > > connection pool.
> > > > >> There are already a couple of modules that do this for you. Which
> > should
> > > > make it fairly easy to implement.
>
> > > > >> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>
> > > > >>> I may just not have found what I'm looking for, but I haven't found
> > > > >>> any readily available mechanism in the Node.js ecosystem for
> > > > >>> distributing the load on a back-end database/store (eg Redis)
> > across
> > > > >>> multiple TCP sockets.  For example, I've only ever seen examples on
> > > > >>> how to use fictorial's redis-node-client with a single socket.  I
> > know
> > > > >>> Redis is fast, but there must come a point when it (or some other
> > > > >>> database connected in a similar way) just won't be able to keep up
> > > > >>> with the queue of requests on the Node.js side via a single socket
> > > > >>> connection.
>
> > > > >>> So I'd be interested to know what work is being/has been done on
> > TCP
> > > > >>> socket pooling within Node.js to allow database load to be spread
> > > > >>> across several threads.  Perhaps there's some examples I've missed?
>
> > > > >>> [Of course databases with an HTTP interface aren't a problem since
> > the
> > > > >>> HTTP layer can do this work for me - so I'm thinking of simple TCP
> > > > >>> socket interfaced databases, Redis being a good example of the
> > genre]
>
> > > > >>> Many thanks!
>
> > > > >>> --
> > > > >>> You received this message because you are subscribed to the Google
> > > > Groups "nodejs" group.
> > > > >>> To post to this group, send email to nodejs@...
> > > > >>> To unsubscribe from this group, send email to
> > > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> >
<nodejs%2Bunsubscribe@...<nodejs%252Bunsubscribe <at> googlegroups. com>
>
> > > > .
> > > > >>> For more options, visit this group athttp://
> > > > groups.google.com/group/nodejs?hl=en.
>
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "nodejs" group.
> > > > > To post to this group, send email to nodejs@...
> > > > > To unsubscribe from this group, send email to
> > > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> >
<nodejs%2Bunsubscribe@...<nodejs%252Bunsubscribe <at> googlegroups. com>
>
> > > > .
> > > > > For more options, visit this group at
> > > >http://groups.google.com/group/nodejs?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "nodejs" group.
> > > > To post to this group, send email to nodejs@...
> > > > To unsubscribe from this group, send email to
> > > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> >
<nodejs%2Bunsubscribe@...<nodejs%252Bunsubscribe <at> googlegroups. com>
>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/nodejs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nodejs@...
> > To unsubscribe from this group, send email to
> > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Jak Sprats | 14 Oct 19:32 2010
Picon

Re: Concurrency - Multiple database connections


As a long time redis user, the speeds or nodejs and redis are approx
the following
on a single 3.0 Ghz Core
1.) redis (for SET/GET) 110K-120K/s
2.) nodejs (for hello-world) 12K/s
               (for a page w/ a single redis INCR) 10K/s

I have been using mranneys node_redis client: http://github.com/mranney/node_redis
(which works w/ node 0.3)
and have been benchmarking nodejs+redis against php+mysql in the redis
dev-group: http://bit.ly/ba2ANx (its an ongoing benchmark)

So you need 10 nodejs cores against 1 redis core to saturate redis
(which is a good ratio because redis does not yet have a cluster:)

On Oct 14, 5:50 am, rtweed <rob.tw...@...> wrote:
> Thanks guys!
>
> On 14 Oct, 13:21, Tim Smart <t...@...> wrote:
>
>
>
> > Redis doesn't need multiple sockets really, as it pipelines requests. (If
> > that was the database you were thinking about using)
>
> > Tim.
>
> > On 15 October 2010 00:48, Arnout Kazemier <i...@...> wrote:
>
> > > Here is something I use in my node-memcached driver;
>
> > >http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection....
>
> > > implementation;
> > >http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L...
>
> > > or:
> > >http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2...
>
> > > On Oct 14, 2010, at 1:23 PM, rtweed wrote:
>
> > > > Yes I understand that and that's what I'm asking - how to create a
> > > > connection pool.  Which modules....and any examples of anyone using
> > > > them with, eg Redis?
>
> > > > On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
> > > >> Threads and multiple sockets are different things. If you want to
> > > connect to your database over multiple sockets, i suggest you create a
> > > connection pool.
> > > >> There are already a couple of modules that do this for you. Which should
> > > make it fairly easy to implement.
>
> > > >> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>
> > > >>> I may just not have found what I'm looking for, but I haven't found
> > > >>> any readily available mechanism in the Node.js ecosystem for
> > > >>> distributing the load on a back-end database/store (eg Redis) across
> > > >>> multiple TCP sockets.  For example, I've only ever seen examples on
> > > >>> how to use fictorial's redis-node-client with a single socket.  I know
> > > >>> Redis is fast, but there must come a point when it (or some other
> > > >>> database connected in a similar way) just won't be able to keep up
> > > >>> with the queue of requests on the Node.js side via a single socket
> > > >>> connection.
>
> > > >>> So I'd be interested to know what work is being/has been done on TCP
> > > >>> socket pooling within Node.js to allow database load to be spread
> > > >>> across several threads.  Perhaps there's some examples I've missed?
>
> > > >>> [Of course databases with an HTTP interface aren't a problem since the
> > > >>> HTTP layer can do this work for me - so I'm thinking of simple TCP
> > > >>> socket interfaced databases, Redis being a good example of the genre]
>
> > > >>> Many thanks!
>
> > > >>> --
> > > >>> You received this message because you are subscribed to the Google
> > > Groups "nodejs" group.
> > > >>> To post to this group, send email to nodejs@...
> > > >>> To unsubscribe from this group, send email to
> > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > > .
> > > >>> For more options, visit this group athttp://
> > > groups.google.com/group/nodejs?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google Groups
> > > "nodejs" group.
> > > > To post to this group, send email to nodejs@...
> > > > To unsubscribe from this group, send email to
> > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > > .
> > > > For more options, visit this group at
> > >http://groups.google.com/group/nodejs?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "nodejs" group.
> > > To post to this group, send email to nodejs@...
> > > To unsubscribe from this group, send email to
> > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/nodejs?hl=en.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Jak Sprats | 15 Oct 00:06 2010
Picon

Re: Concurrency - Multiple database connections

I talked w/ Matt Ranney about putting connection pooling into his
client, and he said it would be easy.

There is a need for connection pooling of some sort w/ redis, as the
thruput for redis is 7Kreq/s at concurrency of 1 and it rises pretty
linearly up to 110Kreq/s at concurrency of 10 and it degrades VERY
slowly from this 110Kreq/s (always on a 3.0Ghz CPU) to about 60Kreq/s
at concurrency of 30K (but the latency is bad at this level)

Here is a writeup of how redis' thruput at different concurrency
levels: http://jaksprats.wordpress.com/2010/09/22/12/

What is important is getting the level of concurrency up to at least
10 to maximise redis' thruput. I know node has backend threads, so
this may provide some level of concurrency, but somewhere between
10-20 is redis' sweetspot.

On Oct 14, 10:32 am, Jak Sprats <jakspr...@...> wrote:
> As a long time redis user, the speeds or nodejs and redis are approx
> the following
> on a single 3.0 Ghz Core
> 1.) redis (for SET/GET) 110K-120K/s
> 2.) nodejs (for hello-world) 12K/s
>                (for a page w/ a single redis INCR) 10K/s
>
> I have been using mranneys node_redis client:http://github.com/mranney/node_redis
> (which works w/ node 0.3)
> and have been benchmarking nodejs+redis against php+mysql in the redis
> dev-group:http://bit.ly/ba2ANx(its an ongoing benchmark)
>
> So you need 10 nodejs cores against 1 redis core to saturate redis
> (which is a good ratio because redis does not yet have a cluster:)
>
> On Oct 14, 5:50 am, rtweed <rob.tw...@...> wrote:
>
> > Thanks guys!
>
> > On 14 Oct, 13:21, Tim Smart <t...@...> wrote:
>
> > > Redis doesn't need multiple sockets really, as it pipelines requests. (If
> > > that was the database you were thinking about using)
>
> > > Tim.
>
> > > On 15 October 2010 00:48, Arnout Kazemier <i...@...> wrote:
>
> > > > Here is something I use in my node-memcached driver;
>
> > > >http://github.com/3rd-Eden/node-memcached/blob/master/lib/connection....
>
> > > > implementation;
> > > >http://github.com/3rd-Eden/node-memcached/blob/master/nMemcached.js#L...
>
> > > > or:
> > > >http://github.com/mrohad/Alligator/blob/79ee8a15d1b50125699c774bb55d2...
>
> > > > On Oct 14, 2010, at 1:23 PM, rtweed wrote:
>
> > > > > Yes I understand that and that's what I'm asking - how to create a
> > > > > connection pool.  Which modules....and any examples of anyone using
> > > > > them with, eg Redis?
>
> > > > > On 14 Oct, 12:03, Arnout Kazemier <i...@...> wrote:
> > > > >> Threads and multiple sockets are different things. If you want to
> > > > connect to your database over multiple sockets, i suggest you create a
> > > > connection pool.
> > > > >> There are already a couple of modules that do this for you. Which should
> > > > make it fairly easy to implement.
>
> > > > >> On Oct 14, 2010, at 1:00 PM, rtweed wrote:
>
> > > > >>> I may just not have found what I'm looking for, but I haven't found
> > > > >>> any readily available mechanism in the Node.js ecosystem for
> > > > >>> distributing the load on a back-end database/store (eg Redis) across
> > > > >>> multiple TCP sockets.  For example, I've only ever seen examples on
> > > > >>> how to use fictorial's redis-node-client with a single socket.  I know
> > > > >>> Redis is fast, but there must come a point when it (or some other
> > > > >>> database connected in a similar way) just won't be able to keep up
> > > > >>> with the queue of requests on the Node.js side via a single socket
> > > > >>> connection.
>
> > > > >>> So I'd be interested to know what work is being/has been done on TCP
> > > > >>> socket pooling within Node.js to allow database load to be spread
> > > > >>> across several threads.  Perhaps there's some examples I've missed?
>
> > > > >>> [Of course databases with an HTTP interface aren't a problem since the
> > > > >>> HTTP layer can do this work for me - so I'm thinking of simple TCP
> > > > >>> socket interfaced databases, Redis being a good example of the genre]
>
> > > > >>> Many thanks!
>
> > > > >>> --
> > > > >>> You received this message because you are subscribed to the Google
> > > > Groups "nodejs" group.
> > > > >>> To post to this group, send email to nodejs@...
> > > > >>> To unsubscribe from this group, send email to
> > > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > > > .
> > > > >>> For more options, visit this group athttp://
> > > > groups.google.com/group/nodejs?hl=en.
>
> > > > > --
> > > > > You received this message because you are subscribed to the Google Groups
> > > > "nodejs" group.
> > > > > To post to this group, send email to nodejs@...
> > > > > To unsubscribe from this group, send email to
> > > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > > > .
> > > > > For more options, visit this group at
> > > >http://groups.google.com/group/nodejs?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google Groups
> > > > "nodejs" group.
> > > > To post to this group, send email to nodejs@...
> > > > To unsubscribe from this group, send email to
> > > > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/nodejs?hl=en.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Matt Ranney | 15 Oct 05:25 2010

Re: Re: Concurrency - Multiple database connections

On Thu, Oct 14, 2010 at 3:06 PM, Jak Sprats <jaksprats-Re5JQEeQqe8@public.gmane.orgm> wrote:
I talked w/ Matt Ranney about putting connection pooling into his
client, and he said it would be easy.

Sure, a simple connection pool would be easy to implement, depending on the strategy for selecting the connection.
 
There is a need for connection pooling of some sort w/ redis, as the
thruput for redis is 7Kreq/s at concurrency of 1 and it rises pretty
linearly up to 110Kreq/s at concurrency of 10 and it degrades VERY
slowly from this 110Kreq/s (always on a 3.0Ghz CPU) to about 60Kreq/s
at concurrency of 30K (but the latency is bad at this level)

Given that redis is 10X faster at being redis than node is, I don't see how having multiple connections from node to redis would make things any faster.  Are you suggesting that the redis engine is actually more efficient at servicing multiple connections than it is when servicing just one?  Maybe because it does slightly more work when processing a large pipeline?  I always figured that the entire system would be more efficient overall with fewer connections comprised of larger packets.

The other case where multiple connections between node and redis could be a big win is if there is any kind of latency or packet loss on the network between node and redis.  With everything pipelining down one connection, a single dropped packet would cut performance dramatically.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
rtweed | 15 Oct 07:58 2010
Picon

Re: Concurrency - Multiple database connections

Even if there is some debate over whether it's needed or not for
Redis, given the general need for connection pooling for most other
backend databases, I'd personally like to see it as a generic function
built into Node.js itself, if that was feasible.  Seems a shame for
every client author to reinvent this wheel.

Rob

On 15 Oct, 04:25, Matt Ranney <m...@...> wrote:
> On Thu, Oct 14, 2010 at 3:06 PM, Jak Sprats <jakspr...@...> wrote:
> > I talked w/ Matt Ranney about putting connection pooling into his
> > client, and he said it would be easy.
>
> Sure, a simple connection pool would be easy to implement, depending on the
> strategy for selecting the connection.
>
> > There is a need for connection pooling of some sort w/ redis, as the
> > thruput for redis is 7Kreq/s at concurrency of 1 and it rises pretty
> > linearly up to 110Kreq/s at concurrency of 10 and it degrades VERY
> > slowly from this 110Kreq/s (always on a 3.0Ghz CPU) to about 60Kreq/s
> > at concurrency of 30K (but the latency is bad at this level)
>
> Given that redis is 10X faster at being redis than node is, I don't see how
> having multiple connections from node to redis would make things any faster.
>  Are you suggesting that the redis engine is actually more efficient at
> servicing multiple connections than it is when servicing just one?  Maybe
> because it does slightly more work when processing a large pipeline?  I
> always figured that the entire system would be more efficient overall with
> fewer connections comprised of larger packets.
>
> The other case where multiple connections between node and redis could be a
> big win is if there is any kind of latency or packet loss on the network
> between node and redis.  With everything pipelining down one connection, a
> single dropped packet would cut performance dramatically.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

Matt Ranney | 15 Oct 08:17 2010

Re: Re: Concurrency - Multiple database connections

On Thu, Oct 14, 2010 at 10:58 PM, rtweed <rob.tweed-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Even if there is some debate over whether it's needed or not for
Redis, given the general need for connection pooling for most other
backend databases, I'd personally like to see it as a generic function
built into Node.js itself, if that was feasible.  Seems a shame for
every client author to reinvent this wheel.

I think this probably does need to be done in each client library.  The strategy, benefits, and mechanism for creating a pool of connections to CouchDB is quite different than those for Redis, and even more different for MySQL.

But perhaps I'm mistaken.  Maybe there's an elegant way to do this generically.  Do other languages/runtimes have an abstract way to make connections to a database?

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Mikeal Rogers | 15 Oct 08:28 2010
Picon

Re: Re: Concurrency - Multiple database connections

I've generalized this in to an http client pool but every other client definitely needs it's own pooling code and API with application specific features.

On Thu, Oct 14, 2010 at 11:17 PM, Matt Ranney <mjr <at> ranney.com> wrote:
On Thu, Oct 14, 2010 at 10:58 PM, rtweed <rob.tweed-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Even if there is some debate over whether it's needed or not for
Redis, given the general need for connection pooling for most other
backend databases, I'd personally like to see it as a generic function
built into Node.js itself, if that was feasible.  Seems a shame for
every client author to reinvent this wheel.

I think this probably does need to be done in each client library.  The strategy, benefits, and mechanism for creating a pool of connections to CouchDB is quite different than those for Redis, and even more different for MySQL.

But perhaps I'm mistaken.  Maybe there's an elegant way to do this generically.  Do other languages/runtimes have an abstract way to make connections to a database?

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
rtweed | 15 Oct 10:21 2010
Picon

Re: Concurrency - Multiple database connections

Perhaps, then, at the very least, one or two examples of the typical
patterns/techniques that were recommended for connection pooling in
Node.js would, I think, be helpful additions to the documentation.

On 15 Oct, 07:28, Mikeal Rogers <mikeal.rog...@...> wrote:
> I've generalized this in to an http client pool but every other client
> definitely needs it's own pooling code and API with application specific
> features.
>
>
>
> On Thu, Oct 14, 2010 at 11:17 PM, Matt Ranney <m...@...> wrote:
> > On Thu, Oct 14, 2010 at 10:58 PM, rtweed <rob.tw...@...> wrote:
>
> >> Even if there is some debate over whether it's needed or not for
> >> Redis, given the general need for connection pooling for most other
> >> backend databases, I'd personally like to see it as a generic function
> >> built into Node.js itself, if that was feasible.  Seems a shame for
> >> every client author to reinvent this wheel.
>
> > I think this probably does need to be done in each client library.  The
> > strategy, benefits, and mechanism for creating a pool of connections to
> > CouchDB is quite different than those for Redis, and even more different for
> > MySQL.
>
> > But perhaps I'm mistaken.  Maybe there's an elegant way to do this
> > generically.  Do other languages/runtimes have an abstract way to make
> > connections to a database?
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nodejs@...
> > To unsubscribe from this group, send email to
> > nodejs+unsubscribe@...<nodejs%2Bunsubscribe <at> googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

ry | 19 Oct 02:20 2010

Re: Re: Concurrency - Multiple database connections

On Fri, Oct 15, 2010 at 1:21 AM, rtweed <rob.tweed@...> wrote:
> Perhaps, then, at the very least, one or two examples of the typical
> patterns/techniques that were recommended for connection pooling in
> Node.js would, I think, be helpful additions to the documentation.
>

here is an example of an http client pool

http://github.com/mikeal/node-utils/blob/dcd3865da535046cc323942110687084fd59adb7/pool/main.js

Jak Sprats | 15 Oct 17:33 2010
Picon

Re: Concurrency - Multiple database connections

> Given that redis is 10X faster at being redis than node is, I don't see how
> having multiple connections from node to redis would make things any faster.

The tests I did were a nodejs webserver where each HTTP request
generated a single redis INCR request. Am I wrong assuming that this
INCR request was a single TCP packet and the redis response was a
single TCP packet. Is your client pipelining backend requests from
DIFFERENT front-end requests? If so, something about that scares me
(it implies blocking until a packet is filled), but if it works, I
guess it would be plenty fast (except in the case where SETs and GETs
had values approaching MTU sizes).

>  Are you suggesting that the redis engine is actually more efficient at
> servicing multiple connections than it is when servicing just one?

YES.
run "./redis-benchmark -c 1 -n 100000 -r 100000" (which will do 100K
redis requests at concurrency level 1)
then run "./redis-benchmark -c 50 -n 100000 -r 100000" (100K reqs  <at> 
concurrency level 50)
The 2nd test will be 7-12X faster.

I think we are miscommunicating somewhat as there are several
variables in play here.
1.) pipelining 20 redis SETs into a single TCP packet is the best of
all worlds
2.) mass-pipelining is not always possible (e.g. in a web-server w/ a
1to5 front-end to backend request ratio)
3.) when mass-pipelining cant be done, then increasing the number of
concurrent connections to redis INCREASES performance.

Redis is really weird in that its performance is better at concurrency
levels of 10 than <10. Think of redis as a tiny amount of software
wrapped around the event-loop. To make redis go real fast, you need to
fill the event loop, and this can be done w/ 10+ concurrent
connections.

I agree w/ your point on the single pipeline being vulnerable to being
a single point where packet loss could lead to performance kinking
(that makes sense to me).

On Oct 14, 8:25 pm, Matt Ranney <m...@...> wrote:
> On Thu, Oct 14, 2010 at 3:06 PM, Jak Sprats <jakspr...@...> wrote:
> > I talked w/ Matt Ranney about putting connection pooling into his
> > client, and he said it would be easy.
>
> Sure, a simple connection pool would be easy to implement, depending on the
> strategy for selecting the connection.
>
> > There is a need for connection pooling of some sort w/ redis, as the
> > thruput for redis is 7Kreq/s at concurrency of 1 and it rises pretty
> > linearly up to 110Kreq/s at concurrency of 10 and it degrades VERY
> > slowly from this 110Kreq/s (always on a 3.0Ghz CPU) to about 60Kreq/s
> > at concurrency of 30K (but the latency is bad at this level)
>
> Given that redis is 10X faster at being redis than node is, I don't see how
> having multiple connections from node to redis would make things any faster.
>  Are you suggesting that the redis engine is actually more efficient at
> servicing multiple connections than it is when servicing just one?  Maybe
> because it does slightly more work when processing a large pipeline?  I
> always figured that the entire system would be more efficient overall with
> fewer connections comprised of larger packets.
>
> The other case where multiple connections between node and redis could be a
> big win is if there is any kind of latency or packet loss on the network
> between node and redis.  With everything pipelining down one connection, a
> single dropped packet would cut performance dramatically.

--

-- 
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nodejs@...
To unsubscribe from this group, send email to nodejs+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.


Gmane