connection Count in JRedisService

[cautious]

Hi,
I want to know if there is a limit to the connection count with
respect to JRedisService (default is given as 5)? If we simply
increase the connection count to a large number, say 100, what side
effects may be there? what is the optimum count in general.


Regards,
Prabin

[Joubin Houshyar]

Hi,

The benchmark classes are pretty useful in getting insights into this.  Bottom line is that there is a finite, fixed, limit in terms of bandwidth and capacity on the server side.   Adding concurrent clients initially promotes efficiency by providing available connections while others are busy blocking on reads or writes.  So, basically there is a sweet spot where under constant load, all your connections are busy, and you are soaking the full bandwidth and processing power of the server.  However, after this point, additional connections simply are excess capacity on the client side and the overhead of switching contexts between the threads starts increasing, until a point where it beings to hamper performance.  

So there is definitely a curve and if you wish to be scientific about it, I suggest you benchmark in your environment with the type of commands/payload sizes that you would normally expect.  Automate that process -- its all java code after all -- and you'll have a data set that you can analyze and pick a good number suitable to your load requirements.

I picked the number 5, relatively out of my hat, since for my localhost benchmarks seems to indicate a sweet spot around 5-10 connections.  

An alternative to JRedisService is the Pipeline.  It uses only a single connection, but given that it only has a single (non-contented) worker element, it handles heavy loads quite gracefully.  

/R

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

[cautious]

Thanks a lot for the detailed explanation. After going through the
benchmarkings, I think i'll go with the pipeline.

Prabin

On Jun 17, 5:28 am, Joubin Houshyar <suno...@gmail.com> wrote:
> Hi,
>
> The benchmark classes are pretty useful in getting insights into this.
>  Bottom line is that there is a finite, fixed, limit in terms of bandwidth
> and capacity on the server side.   Adding concurrent clients initially
> promotes efficiency by providing available connections while others are busy
> blocking on reads or writes.  So, basically there is a sweet spot where
> under constant load, all your connections are busy, and you are soaking the
> full bandwidth and processing power of the server.  However, after this
> point, additional connections simply are excess capacity on the client side
> and the overhead of switching contexts between the threads starts
> increasing, until a point where it beings to hamper performance.
>
> So there is definitely a curve and if you wish to be scientific about it, I
> suggest you benchmark in your environment with the type of commands/payload
> sizes that you would normally expect.  Automate that process -- its all java
> code after all -- and you'll have a data set that you can analyze and pick a
> good number suitable to your load requirements.
>
> I picked the number 5, relatively out of my hat, since for my localhost
> benchmarks seems to indicate a sweet spot around 5-10 connections.
>
> An alternative to JRedisService is the Pipeline.  It uses only a single
> connection, but given that it only has a single (non-contented) worker
> element, it handles heavy loads quite gracefully.
>
> /R
>

> On Wed, Jun 16, 2010 at 9:09 AM, cautious <prabin.mei...@gmail.com> wrote:
> > Hi,
> >   I want to know if there is a limit to the connection count with
> > respect to JRedisService (default is given as 5)? If we simply
> > increase the connection count to a large number,  say 100, what side
> > effects may be there? what is the optimum count in general.
>
> > Regards,
> > Prabin
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "JRedis" group.
> > To post to this group, send email to jre...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > jredis+un...@googlegroups.com<jredis%2Bunsu...@googlegroups.com>
> > .