~ dough ~ Disregard previous, bad key stroke sent rather than save to draft.
Tim Starling wrote: > Michael Dale wrote: > >> That is part of the idea of centrally hosting reusable client-side >> components so we control the jquery version and plugin set. So a >> new version won't "come along" until its been tested and >> integrated. >> > > You can't host every client-side component in the world in a > subdirectory of the MediaWiki core. Not everyone has commit access to > it. Nobody can hope to properly test every MediaWiki extension. > > Most extension developers write an extension for a particular site, > and distribute their code as-is for the benefit of other users. They > have no interest in integration with the core. If they find some > jQuery plugin on the web that defines an interface that conflicts with > MediaWiki, say jQuery.load() but with different parameters, they're > not going to be impressed when you tell them that to make it work with > MediaWiki, they need to rewrite the plugin and get it tested and > integrated. > > Different modules should have separate namespaces. This is a key > property of large, maintainable systems of code. > Right.. I agree the client side code needs more deployable modularly. It just tricky to manage all those relationships in php, but it appears it will be necessary to do so... If designing a given component as a jQuery plug-in, then I think it makes sense to put it in the jQuery namespace ... otherwise you won't be able to reference jQuery things locally and no-conflict compatible way. Unless we create a mw wrapper of some sorts but I don't know how necessary that is atm... i guess it would be slightly cleaner. >> I agree that the present system of parsing top of the javascipt >> file on every script-loader generation request is un-optimized. >> (the idea is those script-loader generations calls happen rarely >> but even still it should be cached at any number of levels. (ie >> checking the filemodifcation timestamp, witting out a php or >> serialized file .. or storing it in any of the other cache levels >> we have available, memcahce, database, etc ) >> > > Actually it parses the whole of the JavaScript file, not the top, and > it does it on every request that invokes WebStart.php, not just on > mwScriptLoader.php requests. I'm talking about > jsAutoloadLocalClasses.php if that's not clear. > Ah right... previously I had it in php. I wanted to avoid listing it twice but obviously thats a pretty costly way to do that. This will make more sense to put in php if we start splitting up components into the extension folders and generate the path list dynamically for a given feature set. >>> Have you looked at the profiling? On the Wikimedia app servers, >>> even the simplest MW request takes 23ms, and gen=js takes 46ms. A >>> static file like wikibits.js takes around 0.5ms. And that's with >>> APC. You say MW on small sites is OK, I think it's slow and >>> resource-intensive. >>> >>> That's not to say I'm sold on the idea of a static file cache, it >>> brings its own problems, which I listed. >>> >>> >> yea... but almost all script-loader request will be cached. it >> does not need to check the DB or anything its just a key-file >> lookup (since script-loader request pass a request key either its >> there in cache or its not ...it should be on par with the simplest >> MW request. Which is substantially shorter then around trip time >> for getting each script individually, not to mention gziping which >> can't otherwise be easily enabled for 3rd party installations. >> > > I don't think that that comparison can be made so lightly. For the > server operator, CPU time is much more expensive than time spent > waiting for the network. And I'm not proposing that the client fetches > each script individually, I'm proposing that scripts be concatentated > and stored in a cache file which is then referenced directly in the HTML. > I understand. (its analogous to making direct links to the /script-cache folder instead of requesting the files through the script-loader entry point ) My main question is how will this work for dynamic groups of scripts set post page load that are dictated by user interaction or client state? Do we just ignore this possibly and grab any necessary module components based on pre-defined module sets in php that get passed down to javascript? Its not as easy to setup static combined output files to point to when you don't know what set of scripts you will be requesting... hmm... if we had a predictable key format we could do a request for the static file. if we get a 404 then we do a request a dynamic request to generate the static file?.. Subsequent interactions would hit that static file? that seems ugly though. > $wgSquidMaxage is set to 31 days (2678400 seconds) for all wikis > except wikimediafoundation.org. It's necessary to have a very long > expiry time in order to fill the caches and achieve a high hit rate, > because Wikimedia's access pattern is very broad, with the "long tail" > dominating the request rate. > oky... so to preserve high cache level you could have a single static file that lists versions of js with a low expire and the rest with high expire? Or maybe its so cheep to serve static files that it does not mater and just leave everything with a low expire? --michael _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
