On Fri, Oct 3, 2008 at 9:50 AM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> It seems to me that parsing Gadget XML should be the least of our worries, > especially if you can insure that the content that's hitting the browser > only varies by country and language and view. Correct me if I'm wrong, but that would seem to be thrown out the window with proxied rendering. > > > By moving the parentUrl to the hash I've been able to accomplish this for > hi5 -- iframes are cached at the browser and CDN level. > > That said this leave out UserPref support, but I'm fine with that as a > tradeoff. > > Perhaps we should focus on delivering the application as one cacheable > chunk and the per-user/preload data in a second chunk? That's actually what type=html applications do, even with __UP substitution (since the UPs are passed on the querystring). Likewise any OpenSocial-templated applications. But proxied throws that out as well, unless we add some caching headers that proxied content rendering can pass back telling us the content is cacheable for all users (eg. it contains only substitution constructs such as templates). Thinking about this some more: 1. It seems unlikely that parsing cost, even if 25ms, will be a substantial component to proxied content rendering latency. Getting the actual, uncacheable data from the app server will be, unless it's specially indicated as cacheable in the first place - at which point we may as well cache the parsed tree as a small optimization. IMO that just calls for passing isCacheable to a caching parser. 2. FWIW, the parsing time of 25ms for BuddyPoke (as with the other numbers) comes from my developer workstation running the test in Eclipse. The numbers are intended to be relative. Kevin -- under which environment did you see 10ms cajoling? Paul, what's your plan for dealing with proxied content latency? -John > > > > On Oct 3, 2008, at 9:35 AM, John Hjelmstad wrote: > > Hi Ian: >> You're right, it's the gadget XML parse prior to manipulation. It's doing >> DOM-based parsing, and I suspect you're right about the load of small >> objects involved. At present I see that as a requirement, though, to deal >> with semi-well-formed input. We've talked about requiring XHTML or >> something >> close to it as a prerequisite for rewriting - which would make parsing >> vastly easier and rather trivial to implement - but that's a spec issue if >> it's to be a general platform requirement. >> >> --John >> >> On Fri, Oct 3, 2008 at 12:53 AM, Ian Boston <[EMAIL PROTECTED]> wrote: >> >> I don't know the precise details of this conversation or exactly which >>> parsing, CajaHtmlParser or XmlUtil.parse, you are talking about, but if >>> its >>> the Gadget XML parse prior to manipulation, and this is still using DOM >>> based parsing, then its probably going to be slower than SAX under load, >>> and >>> vastly slower than Stax. The reason I say under load, is that DOM parsers >>> tend emit lots of small objects which, once they get out of eden, >>> overload >>> the GC which will dominate as resources become scarce. Having said that, >>> gadget parse trees probably don't exist long enough to get out of eden. >>> >>> Ignore me if you are talking about some other parsing going on within >>> gadgets. >>> Ian >>> >>> >>> On 3 Oct 2008, at 02:03, Kevin Brown wrote: >>> >>> The real thing we should be investigating is why it takes 25ms to use the >>> >>>> parser on buddypoke when it only takes 10ms to cajole it. >>>> >>>> >>> >>> > Paul Lindner > [EMAIL PROTECTED] > > > >
