Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: domain of malcolm.edgar@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAM1yOjZ3i_xeP_EG5ttM+SRDq2X6SB8Ce0RZr_yf3EFDWw2Jvg@mail.gmail.com>
References: 
 <CAPFNckhBGeOvQXcJ5C2LpoX-k-DmTv7eisX3HC7RCmQ2jeUU=w@mail.gmail.com>
	<51A69194.1060304@maniatis.org>
	<CAM1yOjZ3i_xeP_EG5ttM+SRDq2X6SB8Ce0RZr_yf3EFDWw2Jvg@mail.gmail.com>
Date: Thu, 30 May 2013 12:02:37 +1000
Message-ID: 
 <CAN-d2bAVPNpoAuCgjTC8cp32=w5E0k9Xic_JedAk1u7tQh4cTA@mail.gmail.com>
Subject: Re: Scale out
From: Malcolm Edgar <malcolm.edgar@gmail.com>
To: user <user@cayenne.apache.org>
Content-Type: multipart/alternative; boundary=e89a8ff2511c778d5e04dde5e416

--e89a8ff2511c778d5e04dde5e416
Content-Type: text/plain; charset=ISO-8859-1

I have found using Caching Groups with relatively short timeouts 15
seconds, can have a huge performance benefit while still keeping most data
quite fresh.


On Thu, May 30, 2013 at 11:21 AM, Mike Kienenberger <mkienenb@gmail.com>wrote:

> And be careful not to overdo it.   I made that mistake in my first
> ecommerce app.
>
> In hindsight, it was sufficient to make sure the data was refreshed at
> the beginning of each request, rather than "as soon as possible".
>
>
> On Wed, May 29, 2013 at 7:39 PM, Aristedes Maniatis <ari@maniatis.org>
> wrote:
> > On 29/05/13 8:14pm, Christian Grobmeier wrote:
> >>
> >> My concern is the Cayenne caching mostly. What if
> >> App1 is doing an update and the next requests select from App2?
> >
> >
> > No one can answer this other than you. What does happen?
> >
> > Are you writing an ecommerce system where data has to be fresh to the
> > millisecond? Or does data need to be consistent per user/session? If the
> > latter, sticky sessions will help you. If the former, you may need to
> remove
> > the cache entirely or use a distributed cache like Terracotta [1]
> >
> > From my own experience with distributed caching, it can get very
> complicated
> > very quickly. Luckily we were able to avoid all caching in the critical
> > parts of the application, and plenty of non-distributed caching in the
> other
> > parts where performance was critical but 20 minutes of staleness was OK.
> >
> > Ari
> >
> >
> > [1]
> >
> http://www.ehcache.org/documentation/2.4/terracotta/distributed-caching-with-terracotta
> >
> > --
> > -------------------------->
> > Aristedes Maniatis
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

--e89a8ff2511c778d5e04dde5e416--