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 <[email protected]> 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 <[email protected] > >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 > > > > > > > > > > > > > > > > > > > > >
