Another secondary thing we can improve (and which we've mentioned in passing during previous meetings) is to cache the results of our API requests across users, presumably at the squid level. I've emailed Ops to see what can be done in that area.
If we achieve this, it would allow us to considerably reduce the average amount of time it takes for the metadata to show up in Media Viewer. This hasn't been the focus of my performance comparison test, which is focusing solely on when the sharp image appears. On Wed, Apr 9, 2014 at 1:51 PM, Gilles Dubuc <[email protected]> wrote: > 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
