That's true, particularly if you're caching the results of these requests (whether in memory or on disk). In practice the issue might not be that problematic depending on how many feature-configurations are used by gadgets rendered by a given server (though the issue will get more pronounced as time goes on). Another option is to learn what feature combinations are most popular and create batched JS files for them. So f1:f2:f3:f4.js could turn into f1:f3:f4.js and f2.js if the former combination occurs often.
Which approach is best will depend on server characteristics (memory, disk, I/O binding), actual gadget feature usage, and browser characteristics, most likely. John On Fri, May 9, 2008 at 2:02 PM, Ropu <[EMAIL PROTECTED]> wrote: > I though about the last approach and reduce to only one extra request. > > But to have all the possible combinations of features in different JS files > would create a LOT of JS files... > > f1.js, f1f2.js, f1f3.js, f1f2f3,js etc, etc. (there are more than 10 > features...) > > perhaps an approach may be to check if the file exists, and if not create > it. This will only add overhead to the first call, and a little more to > check if the file exists in each call. > > ropu > > On Fri, May 9, 2008 at 5:49 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > > > I'm not sure cajoling would be precluded by external <script src> > includes. > > Once Caja's ready, in any case gadget features will have to be carefully > > protected - or, features themselves might be cajoled, which if done in a > > sensible way will allow us to specify symbols which Caja would safely > > export, allowing binding in the gadget space itself. In either case, > again > > it seems Caja's not mature enough for us to define this binding strategy > > yet, so punting is a reasonable option as you say :) > > > > Client-side perceived latency, your second listed risk, is indeed the > > likely > > bigger deal. I'd wager that several sites would be willing to take the > > server-cost hit in exchange for better client-side performance. To what > > extent do you think you could make the approach you use configurable? > > > > Lastly, why need this approach require one request per feature? It could > be > > more efficient to bundle all features together in a single JS request as > > the > > Java JS servlet supports eg. > > <script > src="...feature1-version1:feature2-version2:feature3-version3.js"/> > > > > Granted efficiency of this approach depends on features requested by all > > gadgets on a given page, to facilitate maximum script-sharing, and those > > optimizations are the sort of thing we could add sometime in the future > > atop > > the rendering and RPC calls. > > > > --John > > > > 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. > > > > > > 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 > > > > > > > > > > > > -- > .-. --- .--. ..- > R o p u >
