[00:17:46] <ori>	 dpifke: thanks so much, I really appreciate it! excited to see the data.
[00:18:21] <dpifke>	 Me too!
[06:29:06] <Krinkle>	 looking a bit concerning here https://performance.wikimedia.org/#!/year
[06:29:26] <Krinkle>	 +20 ttfb 
[06:29:35] <Krinkle>	 +300 loadevent
[06:29:45] <Krinkle>	 +400 savetiming
[07:37:12] <phedenskog>	 Krinkle: loadEventEnd seems like it started just some time ago, I can look more into that today see if I can understand why . The save timing graph: just keeps rising and rising.
[07:45:37] <phedenskog>	 Krinkle: That loadEventEnd change that seems to have happened after the 24 of January, I'm not able to see the same in the Navigation Timing data in Grafana? 
[07:47:57] <phedenskog>	 For save timing its the same pattern for p75: https://grafana.wikimedia.org/d/000000085/save-timing?viewPanel=11&orgId=1&from=now-1y&to=now
[09:57:46] <ori>	 I look at that yearly graph often :x
[10:03:18] <ori>	 index.php+load.php wall time is led by db queries (16%), memcached (12%), and curl (6%)
[10:06:28] <ori>	 query performance is a bit neglected, no? is it even tracked meaningfully?
[10:08:00] <ori>	 it used to be logged to graphite (per canonicalized query string)
[10:13:19] <ori>	 Scribunto_LuaSandboxCallback::frameExists looks likes a potential target for optimization. from a very cursory glance at the code it looks like it might get called in places where we know the frame exists (b/c we just created it)
[10:13:58] <ori>	 it's around 2%
[13:52:59] <Krinkle>	 ori: we have an upcoming goal for me and Aaron plus other teams to dedicate time to save timing. However it's been postponed more or less for a year or so (about a year within phab a little longer outside that), since other more urgent stuff keeps propping up taking most of our time. Including a steady stream of new features, growing teams that need on boarding, all whilst both old and new debt keeps not being tended to...