| awight | |
| Jul 30 2015, 9:37 PM |
| F2528029: CN_performance_dataset1.zip | |
| Sep 1 2015, 7:06 PM |
| F2528018: cn_performance_analysis.ods | |
| Sep 1 2015, 7:06 PM |
Splitting this into a subtask.
Compare performance benchmarks before and after deploying the banner history feature and supporting code. Page paint, banner render, and page load timing should not change noticeably.
Consider whether there are any numbers missing from the control, in other words, experiments we'd like to do before the feature is deployed.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | awight | T45250 Redo /beacon/impression system (formerly Special:RecordImpression) to remove extra round trips on all FR impressions (title was: S:RI should pyroperish) | |||
| Declined | None | T90917 Get banner count via Special:BannerLoader | |||
| Duplicate | None | T105109 Create UI for limiting banner impressions (banner diet?) | |||
| Resolved | • atgo | T78089 [epic] Banner History MVP | |||
| Resolved | • AndyRussG | T90918 Banner history mixins and data | |||
| Resolved | • AndyRussG | T107503 Test for performance regressions |
Related note (courtesy @Jdlrobson via @awight -- thx!):
https://lists.wikimedia.org/pipermail/wikitech-l/2015-July/082547.html
Using WebPageTest and a labs instance, I've mostly confirmed that performance of the new code is at least fine, and probably better than existing code.
In the attached spreadsheet, the exec_time column is the number of milliseconds elapsed between when the main centralNotice module is first executed, and when the background call is made to retrieve the banner. In all cases, the new code does better.
However, there are issues with this metric: the points of comparison were (unintentionally) unfair to the old code, because of DOM readiness and how GeoIP code is run. So if there's time, I'd like to re-do these tests using better points of comparison and adding in some new metrics.
Even so, I think the it's clear enough that the new code won't be a major draw on performance.
Since most of work is scripted, it'll be pretty easy to redo and tweak. (I'll send up the scripts in a bit.)