On Fri, May 9, 2008 at 1:31 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> Hey guys, i could do with some advice. > > == the problem == > > In the java version, the features are all parsed and their javascript > content is loaded into memory. This works on the java side, and gives the > opportunity to cajol the entire content in one fell swoop, so that works > great. > > Now on the PHP side of things things are a bit difference since PHP works > in a process-per-request type situation, so parsing the entire features > structure each request is non-doable, would make any semi decent performance > impossible to achieve, so instead i process the features once and cache the > entire resulting structure in cache, thats about twice as fast as processing > the features structure each request, so it's survivable. > > Survivable but far from optimal, it's a lot of information to read from > cache, and a lot of memory consumed (since every process has it's own > instance, it adds up), so that puts a good bit of pressure on the server's > IO. > > To add some measurability to this, on a quad core @ 3ghz workstation this > gets me about 420 pages a second with apache bench. > > == the solution ? == > > The main problem is the overhead of loading all the features javascript > each request, this consumes tons of memory and takes loads of IO, so the > overly obvious solution is to not do this anymore :) > > So what would work is that i make all javascript external (<script > src="...">), generate script tags for each feature (and it's dependencies) > and modify the javascript handler (/gadgets/js) to only output the > javascript for the requested feature. You know this is exactly what the java server does currently when you pass the libs parameter, right? The idea is that the container can aggregate what they expect the most commonly used features to be, and those are handled by /gadgets/js. Everything else is inlined. For example, on a production server: http://sandbox.gmodules.com/gadgets/js/settitle:dynamic-height.js All the iframes on orkut (and other google properties) generate the iframes by setting the most commonly used libraries for the site. For example, on orkut, you might see> <iframe src=" gmodules.com/gadgets/ifr?url...&libs=opensocial-0.7:dynamic-height:setprefs&.. ."> The generated url is then: http://www.sandbox.gmodules.com/gadgets/js/dynamic-height:opensocial-0.7:settitle.js > > There are a few possible downsides i can identify though: > > More requests, one per feature, however with an expiration data in the far > far future and a cache busting version param, this should be negligible.. > besides the amount of bandwidth used would go down tremendously (a few small > kb for a gadget instead of 180kb or so because of all the inline > javascript), so the combined browser side caching of savings on bandwidth / > time to transfer all this info ... should actually have a positive effect > right? > > The second risk is that it could add some perceived latency since the > gadgets.config.init() and the onLoad handlers can't be called until the > document has completed, which includes handling the javascript files, and > whatever external resources the gadget includes.. this is probably the > biggest problem of this solution. > > And finally, it would make cajoling impossible probably ... but that > doesn't concern me so much right now since we don't have a mechanism for php > shindig to do that anyhow :) > > With that 'small' modification, the pages/second shoots up to 630, a very > significant increased, and that's with just a few hacks and not a proper > implementation of this option. > > So the performance gains seem significant enough to consider this, both in > server load, pages/second and bandwidth saved.. however as mentioned, > there's a few risks involved too. > > What do you all reckon would be the right solution here? Hope i can get > your opinions on what would be the better choice here since I'm a bit torn > between the two. > > -- Chris > >
