Thanks all for the details and reminder about Shindig request caching. We'll definitely investigate it along with the other great suggestions everyone made.
-Dave -----Original Message----- From: Louis Ryan [mailto:[email protected]] Sent: Tuesday, January 13, 2009 1:12 AM To: [email protected] Subject: Re: Compressing appData before persistence -- 10K is not enough David, The Proxied content and Invalidation proposals in 0.9 introduce a significant degree of developer control over the lifetime of content in the containers cache beyond HTTP cache semantics. This may be more appropriate for your gadget. -Louis On Mon, Jan 12, 2009 at 5:47 PM, Henning Schmiedehausen < [email protected]> wrote: > Depending on the type of gadget (doing a lot of writes thus > invalidating the cache), caching might not be a solution. If you > return stale data to e.g. a mp3 playlist, users tend to get annoyed. > ;-) > > The cloud solution is pretty much the way to go. We e.g. use a REST > based API to store data and spread the load out. Our Shindig APIs sit > on top of this. > > Ciao > Henning > > > > On Mon, Jan 12, 2009 at 09:31, Chris Chabot <[email protected]> wrote: > > Chewy: Consider your self well informed and not confused at all :) > > > > Shindig's proxy service does a lot of caching, so as long as you set a > > expires / max cache time header on your content, and call makeRequest > with a > > suitable refresh_interval, your sever will be hammered a lot less then it > > would be otherwise. > > > > An extension to the solution could also be to use a cloud service, google > > app engine, joyent and amazon all have great offerings that help you > survive > > becoming popular :) > > > > -- Chris > > > > On Mon, Jan 12, 2009 at 5:08 PM, Chewy Trewhella <[email protected]> > wrote: > > > >> Part of the makeRequest call is a time-to-cache. > >> > >> > http://code.google.com/apis/opensocial/articles/makerequest-0.8.html#cac hing > >> > >> Unless I've managed to totally confuse myself, you should be able to > pull > >> data from the app server, and then cache it for, say, 15-120 seconds > >> (depending on taste), meaning that it's still fresh, but should the user > >> reload the page during that time, it'll pull from the local cache > instead > >> of > >> beating the App Server to death. > >> > >> > >> > >> On Mon, Jan 12, 2009 at 3:56 PM, Citron, David <[email protected]> > >> wrote: > >> > >> > Er, makeRequest sends requests back to the app server, though--the > very > >> > machine we're trying to unload. We wanted to avoid hitting our app > >> > server every time someone refreshes iGoogle, for e.g. > >> > > >> > There are only two logical machines in play here--the gadget container > >> > (Shindig--the persistence host) and the app server (the makeRequest > >> > host), correct? Am I missing something? > >> > > >> > Thanks, > >> > Dave > >> > > >> > -----Original Message----- > >> > From: Chewy Trewhella [mailto:[email protected]] > >> > Sent: Monday, January 12, 2009 10:52 AM > >> > To: [email protected] > >> > Subject: Re: Compressing appData before persistence -- 10K is not > enough > >> > > >> > > > >> > > I suppose we were (naively) hoping that we would be able to use > gadget > >> > > persistence to cache previously-retrieved application data, thus > >> > > reducing the load on our app server during simple page reloads and > the > >> > > like. That's why I was investigating potentially Deflating the data > or > >> > > employing some other kind of compression, though with only 10K per > >> > > gadget*user, even that probably won't be sufficient. > >> > > >> > > >> > Won't makeRequest do this? > >> > > >> > > >
