Diagnostics panel slow?

phiw13 · 2018-02-09 08:39:24

With recent builds of TXP4.7 dev, the Diagnostics panel has become much slower (loading) than it used to be.

First I thought it had something to do with my local environment (new iMac, my testing DB used to be PHP 5.5 + MySQL 5.5.x, now PHP 7.1 + MySQL 5.7.21), but I saw the same slower behaviour on 2 live servers (PHP 7.x + MySQL 5.6.x), and using 3 different browsers.

Bloke · 2018-02-09 09:16:46

When you say ‘slow’ are we talking seconds here? Or just a general feeling compared to other panels?

Looking at the runtimes in the trace log, it does seem as if the Diagnostics panel takes about 4x as long (on average) than other panels to prepare, excluding render time. I was seeing 260-280ms on Diagnostics compared to about 60-100 on most other panels (though that’s not with cleaning DB cache in between, so I ran things a few times as I expected 2nd runs of the same panel to be quicker).

It does do a lot of checksumming and stuff in high diagnostics so I’d expect a longer runtime there, but in low diagnostics there’s not as much going on so it is a bit strange. But it’s the same kind of disparity on 4.6.2. In fact, it seems slower still in comparison to the other panels (excluding Languages which was always slow up until 4.7.0) in my rudimentary tests.

So I’m not sure if this is a general issue with the panel or just the fact it’s collecting so much stuff now. Maybe there are optimizations that we can do (getting more stuff in one resource call vs separate calls, for example), although we can’t do any cacheing for obvious reasons.

Depends if you’re seeing r-e-a-l-l-y slow behaviour or just “a bit slower than other panels”.

Last edited by Bloke (2018-02-09 09:18:02)

phiw13 · 2018-02-09 11:55:55

When you say ‘slow’ are we talking seconds here? Or just a general feeling compared to other panels?

Hmm, a couple of seconds. I click on the menu item, Safari shows the start of the progress widget in the progress bar, then a few (3?) seconds nothing. Same behavior with Firefox (harder to “see” with their silly animation on the tab only). On a live server it is the same (maybe a tad slower to allow for data transfer).

And certainly slower than it was even a few weeks ago (maybe end of december? fuzzy memory). One local site is my venerable playground which is many years and versions of TXP old; the other one is a very recent set up (after I upgraded to a new iMac).

for those two sites I see this:

Venerable playground:
Runtime : 5094.15 ms
Query time: 22.47 ms

Basic install.
Runtime : 5064.16 ms
Query time: 6.74 ms

Bloke · 2018-02-09 14:20:16

phiw13 wrote #309159:

Runtime : 5064.16 ms

Cripes! That’s well over 4.5 seconds more than my playground. Something afoot. Shouldn’t be taking that long.

etc · 2018-02-09 15:16:24

I get ~200ms in Low detail mode. Any clues in debug page source?

phiw13 · 2018-02-10 00:50:39

etc wrote #309163:

I get ~200ms in Low detail mode. Any clues in debug page source?

Here is a plain text version of the whole (anonymised [1]) source of the page: diagnostics

In the trace log , there is a huge jump between line 232 and 233:

32.47 |          | [Rows: 2]
   5063.58 |     0.30 | [SQL: SHOW TABLES LIKE 'txp\_%' ]
   5063.88 |          | [Rows: 17]

That is a week old default install of TXP 47 dev.

¹ admin-user is the TXP user with all privs.

Bloke · 2018-02-10 08:48:59

Just looked in txp_diag.php. In function list_txp_tables, should we name the database we’re searching? What happens if the database contains thousands of Txp installations? Or other systems? That’s a lot to search through with a ‘LIKE’ clause.

I know the query itself is showing as only taking a short time so maybe this is nothing to worry about, but straight after it’s iterating over them all and running CHECK TABLE. I’m a bit fuzzy but isn’t this a cleaner extraction:

SHOW TABLES FROM <database> LIKE '".PFX."txp\_%'"

Or is MySQL clever enough to assume “current” database from our $this->db? Dunno. Seems to be okay according to the trace log, just, meh. Dunno.

We also hard-code textpattern in the results. Is a REGEX better here so we can actually select both or is the assumption better? Multiple LIKE clauses don’t seem to be supported in SHOW calls unless we use WHERE which brings its own baggage.

Maybe this isn’t the culprit but my Spidey-sense is tingling that we could do something a bit better here, regardless.

colak · 2018-02-10 09:23:30

Bloke wrote #309175:

I’m a bit fuzzy but isn’t this a cleaner extraction:

SHOW TABLES FROM <database> LIKE '".PFX."txp\_%'"...

I’m not sure if that means that it can check tables such as pfx_txp_plugins and pfx_textpattern but there are also tables such as adi_notes and smd_macro which might not be able to be extracted from the query… Or maybe they shouldn’t be…

Would another table, listing what should be checked, be a viable solution? This would probably mean some extra code though.

etc · 2018-02-10 15:54:47

Something weird seems to happen between the lines 293 and 380 of txp_diag.php in your case. Try to comment things out and see if it helps.

phiw13 · 2018-02-11 09:26:53

etc wrote #309177:

Something weird seems to happen between the lines 293 and 380 of txp_diag.php in your case. Try to comment things out and see if it helps.

commenting out the block below line 360 (// Test clean URL server vars.): diagnostics loads immediately.
commenting out any of the other if blocks makes no difference.

(I started from the end…)

Textpattern CMS

Textpattern CMS support forum

#1 2018-02-09 08:39:24