Every single add-on update is a pain

[Recep Baltaş]

Sice 2.1, every single update, small or big, is a pain in the arse and it is driving me crazy.

I was about to post the importing template data but I got a better pic that is worth a thousand words:



A nice view from the server where the load is craz high:

 

[Kirby]

$config['db']['emptyMethod'] = 'DELETE';

 

[Recep Baltaş]

I think I should add this to config.php. Purpose?

 

[Recep Baltaş]

No change at all... The stupid process goes no and on until the server crashes.

 

[Kirby]

Hmm, I expected your server to be suffering from TRUNCATE statements that happen a lot on css cache tabels on XenForo upgrades.

This was a known issue for InnoDB in older MySQL/MariaDB versions.

The above setting, which goes into config.php, switches XF behaviour to use DELETE instead.

From your screenshot, the most CPU is being used by MySQL.
What exactly does mysql processlist show?

 

[Recep Baltaş]

I do not know how to check the MySQL processes but during this process, it is all those css.php querries showing up, whicch is normally not there.

 

[Kirby]

Do you have phpMyAdmin (or smth. similar like Adminer)? SHOW PROCESSLIST
Do you have SSH access? mysqladmin processlist

 

[Xon]

This is a known issue with XenForo's add-on install system.

The xf_css_cache table gets hit by a "thundering herd" as all CSS templates are invalidated for every page load during the add-on install or upgrade process, and then every single user that requests a CSS file forces a recompile as the full cache is prevented from being used

My Redis Cache add-on uses the caching provider for CSS for individual template caching so the xf_css_cache table isn't hit by an unexpected large number of writes.

This doesn't really help the XF installer behavior, just migrates some of the symptoms.

 

[Astra]

A similar problem that started after the last update 2.1.5a.
Posted today in hosting and here is their answer:
"Since the beginning of the month, you had 2 times the CPU limit exceeded and today 2, the load was created from a large number of lsphp processes and calls to css.php"

 

[eva2000]

This is a known issue with XenForo's add-on install system.

The xf_css_cache table gets hit by a "thundering herd" as all CSS templates are invalidated for every page load during the add-on install or upgrade process, and then every single user that requests a CSS file forces a recompile as the full cache is prevented from being used

My Redis Cache add-on uses the caching provider for CSS for individual template caching so the xf_css_cache table isn't hit by an unexpected large number of writes.

This doesn't really help the XF installer behavior, just migrates some of the symptoms.

Interesting issue. Maybe have a temp copied table xf_css_cache_stale which can serve stale css cache items to visitors on front end why xf_css_cache is being invalidated/purged ???

 

[Xon]

@eva2000 my add-on just uses redis to cache the individual template output for ~5 minutes (using the style modification and other bits as part of the eky) which helps a pile when older css entries are requested.

 

[Recep Baltaş]

A similar problem that started after the last update 2.1.5a.
Posted today in hosting and here is their answer:
"Since the beginning of the month, you had 2 times the CPU limit exceeded and today 2, the load was created from a large number of lsphp processes and calls to css.php"

Interesting. I also use Litespeed. So the lsphp is Litespeed's PHP handler.

I also have their Cache Plugin installed. Let's summon @Michael A. to this thread to see if they can implement what Xon did with his add-on.

 

[Michael A.]

That IS some interesting behavior, thanks for the ping on this @Recep Baltaş !

I'd definitely be interested in looking into doing similar with our cache plugin once I can find the time.

Added to my to-do