[01:44:50] I'm sad that foo($x=0) doesn't work in PHP, to pass a reference parameter, I must have been thinking of C++ [01:45:03] but foo(...[0]) works [01:45:08] this seems like cheating though [01:55:48] in benchmarking foo(...[0]) is actually slightly faster than $tmp = 0; foo($tmp); although there is a hidden cost in the former in that if the reference is modified, the array will have to be copied [02:30:09] c, I was participating in HHVM rollout yet when the HHVM announcement that made us transition back happened, I was already contemplating starting a discussion about transitioning back because HHVM was just a buggy lagging copycat of PHP and we were hurting MW as an open source project by staying on HHVM. [09:30:12] <_joe_> HHVM as an application server is vastly superior to php-fpm [09:31:24] <_joe_> and before saying switching to hhvm was a mistake, I'd remember the api cluster was lagging behind with constant cpu usage above 85% (with almost twice as many servers as today) [09:32:23] <_joe_> so, while we could've waited two years and endure the pain for that long, it was definitely much better to move [16:14:56] Hey, I need reviewers for UBN patch - https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/498809/ [16:15:39] sadly, it's train blocker. [16:20:39] TimStarling: Seems that for excimer the stacks aren't published in the correct format [16:20:45] xenon: 3) "api.php;{GET};/srv/mediawiki/php-1.33.0-wmf.22/api.php;/srv/mediawiki/php-1.33.0-wmf.22/includes/WebStart.php;/srv/mediawiki/php-1.33.0-wmf.22/includes/Setup.php;/srv/mediawiki/php-1.33.0-wmf.22/LocalSettings.php;/srv/mediawiki/wmf-config/CommonSettings.php;/srv/mediawiki/private/PrivateSettings.php;AutoLoader::autoload;/srv/mediawiki/php-1.33.0-wmf.22/includes/AutoLoader.php;AutoLoader::autoload 1" [16:20:52] excimer: 3) [16:20:52] "/srv/mediawiki/w/api.php;/srv/mediawiki/php-1.33.0-wmf.22/api.php;/srv/mediawiki/php-1.33.0-wmf.22/includes/WebStart.php;/srv/mediawiki/php-1.33.0-wmf.22/includes/Setup.php;MediaWiki\\Session\\SessionManager::getGlobalSession;WebRequest::getSession;MediaWiki\\Session\\SessionManager::getSessionForRequest;MediaWiki\\Session\\SessionManager::getSessionInfoForRequest;CentralAuthSessionProvider::provideSessionInfo;User::isUsableName;Message::plain [16:20:52] ;Message::toString;Message::fetchMessage;MessageCache::get;MessageCache::getMessageFromFallbackChain;MessageCache::getMessageForLang;MessageCache::getMsgFromNamespace;MessageCache::load;Language::getMessageKeysFor;LocalisationCache::getSubitemList;LocalisationCache::getSubitem;LocalisationCache::loadSubitem;LocalisationCache::loadItem;LCStoreCDB::get 1" [16:21:10] ugh, I mean "api.php;{GET};/s..." vs "/srv/mediawiki/w/api.php;/s..." [16:24:31] Ha, well, actually the part I'm worried about for xenon-log.py works fine, it ignores everthing until the first slash before a semicolon. But we are missing the HTTP verb. Not high prio in that case. [19:09:32] HHVM -> PHP 7 retrospective blog post(s) would be a very interesting read [22:23:35] Krinkle: it may have been a deliberate change since I remember thinking that adding the HTTP verb was a bit of a nuisance [22:25:43] TimStarling: Hm. I agree we can remove it, but seems like it wasn't intentional. The preg_match isn't matching. [22:25:50] in profiler.php [22:25:55] right [22:26:00] subconsciously undermined then ;) [22:26:14] That leaves scriptFilename which we would still need to prepend. [22:26:50] Although it would appear to already work because unlike HHVM, it seems PHP 7 also includes the non-multiversion stack entry of "/srv/mediawiki/w/api.php" which is interesting. [22:27:00] And that already matches the pattern xenon-log.py looks for to group the traces. [22:27:53] OK. I'll just remove it then, np. [22:27:57] thx [22:54:20] TimStarling: Are you aware of cases where the first frame isn't the entry point / php script being executed? [22:54:25] The comment suggests so [22:55:55] you mean "The last element is usually (but not always) the full file path of the script name."? [22:58:11] that comment was copied from the xenon code [22:58:24] it is true of php -a [22:58:39] I don't know if there are other cases, like shutdown functions? [23:02:25] Hm.. interesting. [23:03:46] TimStarling: so for CLI, afaik we disable profiling there. But need to confirm. If it does end up enabled, it would just create another entry point automaticaly which I fine I suppose. [23:04:12] if we want that, but right now, we don't. Just to say it doesn't need explicit handling, but we do need to make sure it's off for PHP 7 just as it is off for HHVM. [23:04:35] for shutdown functions, aye, right, I guess the stack unrolls for that including for the entry point. I'll have to confirm that. [23:05:00] Could you confirm about excimer in CLI being off ? [23:13:10] I think I confirmed it when I wrote this, but reviewing now, profiler.php is only included from PhpAutoPrepend.php, which is only the auto prepend file for the fpm SAPI [23:13:34] it's only in /etc/php/7.2/fpm/php.ini on the mw* servers [23:14:58] profiler.php used to be included from CommonSettings.php, but that was removed, so I don't think it is possible to profile in CLI mode anymore [23:17:05] Ah, I didn't realise prepend was web-only. [23:17:06] interesting. [23:17:16] I guess it is supported on CLI, but we only configure it in cgi mode [23:17:22] Cool, that makes sense [23:17:42] I am getting stacks with "Wikimedia\Rdbms\LBFactory::__destruct;Wikimedia\Rdbms\LBFactory::destroy;" as their first frame from redis/excimer [23:18:15] So we'll need to make sure to prepend SCRIPT_FILENAME or some such as first entry there. I don't want to get the per-site docroot in there though, so maybe something hacky with realpath() [23:18:20] and to only add if not there already? [23:19:42] For hhvm/xenon, I see the destruct traces have the entry point natively, but post-shutdown doesn't. Those are currently fine because we prepend the basename (they otherwise start with "MediaWiki::doPostOutputShutdown;") [23:30:55] right, it makes sense that destructors would be called without the script file in the stack [23:31:33] it's surprising that we still have /w in separate directories, those could easily be aliased into the same directory in the apache config [23:35:03] TimStarling: wikibooks/ -> standard-docroot/, and standard-docroot/w -> srv/mediawiki/w/ [23:35:31] There used to be some files differing within /w/ per domain, but I think we mostly got rid of that, only very recently [23:35:47] but for .php probably not. [23:36:24] yeah, everything uses symlinks [23:36:37] I mean, apache config is pretty scary, it's a rabbit hole, so I get it [23:37:39] :) [23:37:50] Chad did a bunch of amazing work around this