Shindig - Java Scalability metrics

[Priya Joseph <el...@yahoo.com>]

Hi,

I can't seem to locate any shindig scalability metrics. Can
you share? Can you share your lessons learnt scheme of things as well?
Isn't it amazing how we take battle-arrows-on-your-back for free lunch:)

This
maybe a noob question - but do you recommend colocating the gadget
server where shindig is located?In the google gadget server
implementation, how are you colocated? And how do you split and amp
shindig caching with the usual portal caching layers? Looking for best
practice primarily,

Thanks much,
Priya






      


      

Re: Shindig - Java Scalability metrics

[Kevin Brown <et...@google.com>]

One meaningful limit to performance that I've encountered is the current
performance of JUEL. In an extreme case, expression evaluation cost us about
50% of our CPU time. This won't affect scalability in general, but it does
mean that if you have a lot of gadgets that do a lot of expression
evaluation you will need much more hardware than if you do not. If anyone
has the time to revisit this (perhaps trying MVEL, which is supposed to be
much faster), it would be helpful.
On Wed, Aug 26, 2009 at 8:19 AM, Paul Lindner <li...@inuus.com> wrote:

> Shindig can run in a very high volume environment -- the only thing you
> have
> to be careful about is how you implement your person/activity/appdata
> handlers.  Sorting and filtering can be problematic, especially if your
> backend does not already do that for you.
> I have observed shindig servers pushing 600 req/sec on commodity hardware.
>
> The built-in ehcache does quite well for smaller environments, a shared
> distributed cache like memcache would be recommended if you run a cluster.
>  The gadget server can be separate from your container for the most part --
> just make sure that it has low latency connectivity to your backend data.
>
> On Fri, Aug 7, 2009 at 12:10 PM, Priya Joseph <elletripathi@yahoo.com
> >wrote:
>
> >
> >
> > Hi,
> >
> > I can't seem to locate any shindig scalability metrics. Can
> > you share? Can you share your lessons learnt scheme of things as well?
> > Isn't it amazing how we take battle-arrows-on-your-back for free lunch:)
> >
> > This
> > maybe a noob question - but do you recommend colocating the gadget
> > server where shindig is located?In the google gadget server
> > implementation, how are you colocated? And how do you split and amp
> > shindig caching with the usual portal caching layers? Looking for best
> > practice primarily,
> >
> > Thanks much,
> > Priya
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

Re: Shindig - Java Scalability metrics

[Priya Joseph <el...@yahoo.com>]

Thanks Paul

--- On Wed, 8/26/09, Paul Lindner <li...@inuus.com> wrote:

From: Paul Lindner <li...@inuus.com>
Subject: Re: Shindig - Java Scalability metrics
To: shindig-dev@incubator.apache.org
Date: Wednesday, August 26, 2009, 8:19 AM

Shindig can run in a very high volume environment -- the only thing you have
to be careful about is how you implement your person/activity/appdata
handlers.  Sorting and filtering can be problematic, especially if your
backend does not already do that for you.
I have observed shindig servers pushing 600 req/sec on commodity hardware.

The built-in ehcache does quite well for smaller environments, a shared
distributed cache like memcache would be recommended if you run a cluster.
 The gadget server can be separate from your container for the most part --
just make sure that it has low latency connectivity to your backend data.

On Fri, Aug 7, 2009 at 12:10 PM, Priya Joseph <el...@yahoo.com>wrote:

>
>
> Hi,
>
> I can't seem to locate any shindig scalability metrics. Can
> you share? Can you share your lessons learnt scheme of things as well?
> Isn't it amazing how we take battle-arrows-on-your-back for free lunch:)
>
> This
> maybe a noob question - but do you recommend colocating the gadget
> server where shindig is located?In the google gadget server
> implementation, how are you colocated? And how do you split and amp
> shindig caching with the usual portal caching layers? Looking for best
> practice primarily,
>
> Thanks much,
> Priya
>
>
>
>
>
>
>
>
>
>



      

Re: Shindig - Java Scalability metrics

[Paul Lindner <li...@inuus.com>]

Shindig can run in a very high volume environment -- the only thing you have
to be careful about is how you implement your person/activity/appdata
handlers.  Sorting and filtering can be problematic, especially if your
backend does not already do that for you.
I have observed shindig servers pushing 600 req/sec on commodity hardware.

The built-in ehcache does quite well for smaller environments, a shared
distributed cache like memcache would be recommended if you run a cluster.
 The gadget server can be separate from your container for the most part --
just make sure that it has low latency connectivity to your backend data.

On Fri, Aug 7, 2009 at 12:10 PM, Priya Joseph <el...@yahoo.com>wrote:

>
>
> Hi,
>
> I can't seem to locate any shindig scalability metrics. Can
> you share? Can you share your lessons learnt scheme of things as well?
> Isn't it amazing how we take battle-arrows-on-your-back for free lunch:)
>
> This
> maybe a noob question - but do you recommend colocating the gadget
> server where shindig is located?In the google gadget server
> implementation, how are you colocated? And how do you split and amp
> shindig caching with the usual portal caching layers? Looking for best
> practice primarily,
>
> Thanks much,
> Priya
>
>
>
>
>
>
>
>
>
>