Looking at the timing waterfall, I think that the answer is simply the thumbnail info API call, for which Gergo has a WIP solution: https://gerrit.wikimedia.org/r/#/c/124796/
Basically at the moment Media Viewer (unlike the File: page) has to get the results of a PHP API call before it knows the URL of the image to load. My hunch, seeing that on my machine the API calls can take up to a full second, is that the 25% overhead will go away entirely when that improvement gets merged. On Wed, Apr 9, 2014 at 1:28 PM, Gilles Dubuc <[email protected]> wrote: > Hi, > > Cold cache concerns aside (see the other email I just sent), I now have > preliminary performance figures comparing Media Viewer to the status quo > (File: page) in production. I'm still working with QA on getting our test > merged and running automatically on cloudbees. The results I have were > performed on a 2MB DSL connection in France, with nothing else running on > the network. > > Since we don't collect browser resolutions in our own stats (that I could > find) I picked "average" and "large" desktop browser window sizes based on > 3rd-party "internet-wide" statistics I could find online. These statistics > differentiated desktop and mobile, so mobile's lower resolutions didn't > affect the average. The "small" size was picked specifically to hit a > bucket size identical to the File: page's image. > > On an small browser window size (900x700), Media Viewer displays the image > in a little less than 125% of the time it takes to display the image on the > File: page > > On an average browser window size (1366x768), Media Viewer displays the > image in a little less than 125% of the time it takes to display the image > on the File: page > > On a large browser window size (1920x1080) I found the same result, but I > suspect it might not be true, because my desktop wasn't big enough to > accommodate that size in selenium's Firefox. I think we'll need to wait for > cloudbees to run the tests headless for the real figure. > > For the sake of argument, let's look at the difference in file size > between the file page and the "average" browser size: > > > http://en.wikipedia.beta.wmflabs.org/wiki/File:Sunrise_over_fishing_boats_in_Kerala.jpg > > - on the File: page, the image displayed is 800x600 (480,000 pixels) and > weighs 52.7kb > - on Media Viewer, at the "average" browser resolution, the image > displayed is 1024x768 (786,432 pixels) and weighs 79.6kb > > Therefore, the Media Viewer image has 63.8% more pixels on the screen and > weighs 51% more. > > But, this is only a consolation prize, because the small browser window > size (900x700) which serves the same 800x600 image as the File: page still > takes 20-25% longer, which seems to indicate that Media Viewer's overhead > isn't due to the image size. Basically, if we made the File: page serve a > 1024x768 image, it would certainly still beat Media Viewer. > > We've already done multiple rounds of optimizing the performance of Media > Viewer, but I'll investigate further to see if there's anything obvious > that makes Media Viewer slower than opening the File: page. > > In my opinion between 20 and 25% of overhead isn't a show-stopper for > launch, considering that Media Viewer serves a bigger image in most > situations, but it's worth giving optimizing one last try to see if we've > missed anything. However, it could very well be that we can't do better and > that the overhead is due to doing adding the image dynamically with JS > instead of it being present in the pageload DOM of a relatively lightweight > page. >
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
