Hi @dwinden,
Thanks for coming back on this!
I had this problem for almost a year now, and I finally wanted to get it sorted out. It turned out to be iTSec.
I hope this doesn’t come over “obnoxious”, just posting my professional knowledge in a short yet detailed fashion on the details missing :).
And no, your “brief manually written
<ol> to form a simple checklist” is not much help.
Too much details missing. Like number of sites in network, other active plugins , MySQL, PHP, Webserver, iTSec plugin version, browser (version) used, server specs etc etc
number of sites in network : Irrelevant, as each site is independent of database and plugin interaction.
other active plugins : That’s why I posted it here, for others to be replicated.
MySQL : Irrelevant, as WordPress handles these. But uh, MariaDB 10.x I think. Also MySQL 5.4.x I believe (I switched a while back).
PHP : Irrelevant, PHP either just works, or crashes if non-existent functions are used. Badly written loops are bad irregardless of PHP version. Nevertheless, 5.6.x.
Webserver : Irrelevant, as a Webserver is merely a transport layer which WordPress handles, completely… A working PHP package with default compatible PHP functions shouldn’t slow things down for 10 to 20x its speed. PHP also stands aside from server configuration. But FYI, Apache 2.4.x on CentOS 6.5 to 6.7.
iTSec version : Latest, which should be regarded as default, especially since the new big green Tip before posting support topics asks you to :). Also dates to iTSec versions to almost a year ago.
browser : Irrelevant. PHP script is slow, not the browser. iTsec should check for browser things at the front-end, not logged-in back-end. But FYI, IE, Edge, Firefox, Safari and Chrome. All on Windows except for Safari.
Preamble
The iTSec dev team should know, or even dream their code. Maybe this lights up a bulb :).
In conclusion:
This 10x to 20x performance hit should indicate a timing script, maybe even a remote request which fails. This is about 2 to 3 seconds of extra load time on PHP 5.6.x.
This only occurs when a non-super-admin is logged in.
So any code which checks for that on a website, which evidently only runs on a MultiSite and which is the main blog should hint that there’s some very specific conditional code firing this.
The 8 conditions are very elaborate, I believe these few extra will also greatly help filtering down to the issue.
I hope this clears things up and I hope you can deliver this to the devs! Thanks and have a wonderful day :).
P.S. I’ve been working now for 19 hours straight, reading back on this, I can see it sounds irritated, or maybe I interpret it that way… who knows? But it’s all done to share and learn! 🙂 Keep up the good work!
