[01:30:41] <^d> Krinkle: Generally speaking, scopedProfileIn() is for non-functional units or functional units that are otherwise opaque to profiling. Any use of it is explicit from when we were nuking wfProfile* calls. [01:31:20] ^d: Yeah, I remember. hence I though this may've been a left over [01:31:48] ^d: Do we actually have xhprof in prod now? Where are the results? We had our old profiling in like 10 different places over time, they're all 404 now. [01:32:06] <^d> It should go in graphite now? [01:32:16] Graphite is not an interface. [01:32:23] I wanna see pretty graphs and relations. [01:32:28] tables [01:32:31] <^d> I was just thinking that the other day [01:32:34] <^d> I miss profile.cgi :) [01:32:36] actionable stuff [01:32:38] Yeah [01:33:10] The walkeable tree with sub items that are part of the other, nested methods etc. [01:33:23] <^d> Anyway, the data should get stuffed into Graphite now so coaxing graphs and such out of it shouldn't be impossible [01:34:07] ^d: I'm suspicious of whether a graph would be the best interface of extracting and presenting this data [01:34:17] I suppose it can show the performance of an individual method over time. [01:34:18] <^d> True [01:34:22] But that assumes you already know which method to look at [01:34:26] <^d> Yeah [01:34:41] Not which method is a supet set of an ahother and which method is taking the most time. [01:50:43] "I mentioned in the Simplicity/Ease of Use section that I had started this project by developing with Ansible and then re-implementing in Salt, but as time progressed I started implementing in Salt while Ansible was running. By the time I got half-way through implementing in Ansible I had already finished implementing everything in Salt." [01:50:49] – http://ryandlane.com/blog/2014/08/04/moving-away-from-puppet-saltstack-or-ansible/ [01:50:53] Nice! [01:50:54] :D [01:51:27] ^d: Who was mostly behind changing us to xhprof? [01:52:10] <^d> Myself and Aaron [20:15:18] MaxSem: do you have any cycles for https://phabricator.wikimedia.org/T97096 ? [20:15:35] I don't think Prtksxna is going to be able to do that by himself [20:15:52] it's like 2 minutes of wotk [20:15:54] looking [20:17:01] also, why this channel is still a thing? :P [20:22:54] habits [20:24:28] because _security is invite-only, -operations is full of alert spam, -dev is full of bot spam, #mediawiki is user-oriented, -tech is too quiet, and the rest are too topical [20:26:18] ori, public function getCacheMode( $params ) { [20:26:18] return 'public'; [20:26:18] } [20:27:17] does it inherit from ApiQuery? [20:27:58] ApiQueryBase [20:28:44] it doesn't call parent::execute though [20:29:11] so there is nothing to call getCacheMode [20:30:56] parent::execute() is abstract [20:31:57] so maybe it's up for subclasses to remember to call $this->getMain()->setCacheMode( $this->getCacheMode() ) ? [20:32:10] you're mixing up ApiQuery and ApiQueryBase [20:32:33] whatever the reason, it is not getting set [20:32:50] we are well over the two minute mark, by the way :P [20:33:25] well, my fix was already in place [20:33:34] i would kill the method because of the whole inheritance clusterfuck and just call setCacheMode and setMaxAge [20:34:32] don't do that [20:34:38] I'm not doing anything [20:34:49] other than recruiting you to fix it :) [20:35:27] because setting cache mode blindly doesn't work with query api which combines several modules, some of which can be private [20:46:30] err ApiMain::setCacheMode: downgrading cache mode 'public' to 'anon-public-user-private' due to uselang=user [20:47:31] anomie, that doesn't sound right ^^^ [20:48:15] is all API caching screwed up? [20:49:17] yup, $INSERTCOREAPIMODULEHERE also returns an uncacheable result [20:52:40] ori, NOT MY BUG!!1 [20:52:42] :P [22:42:22] MaxSem: (a) is there a task for this bug? (b) were you able to isolate it to a particular commit? [22:43:34] ori, (a) I converted your bug (b) I remember Brad messing with languages [22:43:51] ah cool, I didn't see the update [22:43:53] looking now [22:43:54] thanks!