[02:13:43] Any sysadmins around? [02:20:49] looking for assistance with a global rename [02:24:31] what do you need exactly? [02:25:53] Krenair: Rename for user with 244k edits [02:26:48] does the system prevent that without our help? [02:27:39] "You must ask a sysadmin (Legoktm or Hoo)." [02:28:38] If there's no corresponding document for our end, it should go via legoktm or hoo only [02:28:47] damn, okay [03:02:36] RileyH: file a ticket in phabricator and add legoktm as a subscriber [03:25:42] We should document what we do. [04:39:39] legoktm: file a ticket in phabricator and add legoktm as a subscriber [04:39:43] derp >.> [05:03:41] is this IRC for general tech discussion? [05:09:18] anyone on? [05:11:03] ya [05:17:02] so I'm wondering you know how smartphones can be bought either unlocked or locked thru a carrier [05:17:25] lol for wikimedia ONLY tech... [05:17:50] great >.< do you know of any general tech ircs [05:18:14] #tech ? [05:50:58] hi [05:51:10] i want to ask [05:52:06] how to change [05:56:07] hi [13:47:52] The Gerrit Tutorial has a section about "Pushing via HTTPS when SSH is not functional". How would a user realize that SSH is not functional? And how would a Gerrit user realize that they are actually behind a proxy server? [15:19:09] Could anyone with shell access look up the stacktrace(s) for the MWExceptions in https://phabricator.wikimedia.org/T134388 please? Thanks in advance [15:19:29] Whoops. Sorry, Alex did that in the meantime already. Ignore my request. [15:19:36] :) [15:20:40] Krenair: You're fast, man. Thank you a lot! :) [17:57:28] <[riley]> legoktm: i want to login :( [17:57:34] <[riley]> you broke me!! [17:57:35] <[riley]> xD [18:00:21] [riley]: sorry, it's going to take a few hours :S [18:00:33] <[riley]> i assumed i could log in on wikis it was done [18:00:34] <[riley]> :( [18:00:56] <[riley]> the only thing more depressing than this is that irc won't let my nick be ~riley [18:03:43] hello, does WMF report browser usage stats? if so where can I see this information [18:05:06] I found it, thanks https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [18:06:07] or actually, looks like this has been discontinued? [18:08:06] sorry for thinking out loud, for anyone interested it's at https://browser-reports.wmflabs.org :) [18:09:55] * [riley] was interested [18:11:00] I think I can drop support for IE10 on my Tool Labs projects [18:11:52] I've spent too long trying to figure what broke [18:13:30] andre__: Re "realize SSH is not functional", the most common way I've seen to test if ssh is working is ssh -p 29418 username@gerrit.wikimedia.org [18:16:55] RoanKattouw: thanks. I'll pick that up for the docs. [18:17:02] That should print a message like "welcome to Gerrit, we don't support direct ssh". If it errors out or times out, that means there's an issue with SSH. [18:17:23] If the error message is "Permission denied", then often there's an auth problem, like they are using the wrong user name or their key isn't set up correctly [18:17:30] But if it's something else, they likely have trouble reaching the server [18:45:24] <[riley]> 92 wikis left.. [18:57:54] <[riley]> legoktm: is it stuck? [19:34:17] <[riley]> legoktm: "Exception encountered, of type "LogicException"" [20:45:34] [riley]: what is saying that? [20:59:26] <[riley]> legoktm: CentralAuthor [20:59:32] link? [20:59:35] are you able to login? [21:00:19] <[riley]> working now.. [21:00:24] <[riley]> guess the two hour delay solved the problem [21:00:58] yeah, it just takes a while :) [21:59:28] so WatchedItemStore::$cache is always a HashBagOStuff? [21:59:35] TimStarling: yes [21:59:56] When that bit of watched item caching logic was in User it was using a ProcessCacheLRU [22:01:38] sorry, not User, Title... [22:01:40] ok, but it still supports LRU [22:03:13] and you are thinking about making it a shared cache? [22:03:31] and you're also thinking about removing it? [22:03:40] yes to both [22:04:40] In my eyes anyway the current caching seems to be in the middle of being useful and useless., and it should probably move in one direction or the other [22:05:21] at least HashBagOStuff has a low overhead, it doesn't do much harm even if it has a low hit rate [22:06:11] okay, and in the case that we want to keep it I may split the caching out into a CachedWatchedItemStore to untangle it a bit [22:06:56] infact when this was in User it was simply maintained as an array in the User object with a maximum object count of 100 [22:10:10] presumably, as DanielK_WMDE said, the dominant (highest traffic) use of this class is from the skin [22:11:02] presumably, through User::isWatched, which is likely why some level of caching was there [22:11:18] yes, from SkinTemplate.php line 1045 [22:12:05] if you just have a shared cached for isWatched(), you don't need to purge that when the notification timestamp changes [22:12:36] I wonder where the cache hits come from [22:12:44] existing cache hits [22:13:20] well, if isWatched is called, the item is loaded, so every subsequent call would be cached, or vice versa [22:14:14] EditPage probably causes a few cache hits, it has the star in the skin and also prefills the "watch this page" checkbox with the current state [22:14:46] do you know how long isWatched() takes for a cache miss? [22:15:10] I havn't profiled it at all [22:15:22] our production profiling is so crappy these days, we probably have no idea [22:15:41] :/ [22:15:51] function wall clock time is not collected is it? [22:16:17] *goes to hunt for stuff* [22:16:20] I think it is in the sampled data that ori uses to make the flamegraphs [22:16:23] in general I am skeptical about caching very simple, single-row slave queries [22:16:39] because slave DB queries are quite fast and scalable already [22:16:44] but I don't remember if there is an easy way to dig through it [22:16:51] bd808: I think it might be CPU time not wall clock time [22:16:59] oh that may be true [22:17:13] which is not useful for comparing DB with memcached [22:17:23] I think memcached is a bit faster, but both are <1ms [22:17:30] https://performance.wikimedia.org/xhgui/run/symbol?id=572a73801b2f383b5ed55ad4&symbol=WatchedItemStore%3A%3AisWatched [22:17:36] oh, you use the watchlist group [22:17:49] the watchlist query group [22:17:54] yes [22:18:08] you should probably stop doing that [22:19:09] it will add connection overhead, which is probably larger than the whole query time, and the point of that query group is that it has an optimised recentchanges table [22:19:19] which you don't even use [22:19:51] TimStarling: What makes our production profiling so crappy these days? We lost the automatic sampled profiling of all functions -> graphite, but that's because graphite did not have enough capacity. That is a regression, but there are several new tools that are quite powerful, so I'm not sure the decline narrative is justified. [22:20:30] the decline narrative? [22:20:48] things being so crappy these days [22:21:45] graphite never provided profiling in the first place... [22:21:51] TimStarling: interesting, so the whole class should basically avoid using the watchlist group? [22:22:37] we had function- (and section-) level profiling data in graphite for a substantial period of time. is it report.py that you are mourning? [22:22:52] report.py was something at least [22:23:26] the flame graphs and xhgui make up for it, but I am willing to bet you haven't spent much time with either [22:23:36] no I haven't [22:24:47] addshore linked to it but it seems wrong? [22:25:06] is there some way to find out how much wall clock time is used by WatchedItemStore::isWatched()? [22:25:16] TimStarling: yeh loadWatchedItem is never called in that sampeled run, I need to find one wiht a logged in user [22:25:24] otherwise it bails out early and we see nothing [22:25:49] but I have no idea how to find a logged in request on xhgui or find a request that hits a specific method [22:27:12] addshore: you can make profiled requests using the chrome and firefox plugins -- https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug [22:27:33] bd808: and they will appear in the recent runs list? [22:27:33] bd808: still just a single request though [22:27:42] TimStarling: yeah [22:28:01] report.py used to tell us how long a function took aggregated over thousands of requests [22:28:27] addshore: you will actually get a link the the profile. chrome puts it in the page footer, firefox adds it to the right-click context menu [22:28:36] bd808: oooooh [22:31:38] the flame graphs don't give you wall clock time, but they tell you the proportion of time a function is on-CPU across the cluster [22:32:35] How long does a profiled request that I was given the link to buy the extension usually take to get to xhgui ? [22:32:52] a few seconds [22:35:22] bingo [22:37:27] https://performance.wikimedia.org/xhgui/run/symbol?id=572a78eaacaf1ded195c79e0&symbol=WatchedItemStore%3A%3AgetWatchedItem [22:38:12] and yes, most of the time is spent acquiring a connection [22:38:24] in this instance [22:38:27] fluorine:~$ xenon-grep --grep isWatched [22:38:28] Top 20 functions in traces matching "isWatched", all entry-points: [22:38:28] ------------------------------------------------------------------ [22:38:29] 1 | WatchedItemStore::getConnection | 32.32% [22:38:31] 2 | WatchedItemStore::loadWatchedItem | 28.28% [22:38:33] 3 | User::isWatched | 16.16% [22:38:35] 4 | WatchedItemStore::getDefaultInstance | 5.05% [22:38:37] 5 | WatchedItemStore::__construct | 4.04% [22:38:47] yup [22:39:17] back in 10 [22:39:19] okay, so avoiding the watchlist group there would be a thing to do [22:39:32] I'm going to have to head off now, getting late and I have an early start! [22:40:11] me too, bye