Issue PHP JIT not enabling with plesk performance booster

[JohnWest]

Server operating system version

Ubuntu 22.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian v18.0.63_build1800240902.09 os_Ubuntu 22.04

Hello folks!

I use PHP FPM server by apache. (8.3.11) -
I've enabled the performance booster directives regarding JIT.

When I check if JIT is active using opcache-gui I get this message : "No (incompatible with extensions that override zend_execute_ex(), such as xdebug)"


Note, to use opchache-gui, I have to allow opcache_get_status (removing it from the disabled functions). That's the only change I made, all the rest is the default plesk config, from using the PHP-FPM server by apache (not dedicated), with all performance booster settings applied out of the box.
I don't have any other directives added to the site / or made modifcations to the php.ini files.

I checked in the Tools, PHP and xdebug is toggled off.

Not sure what else could block JIT from effectively work

This is not an isolated case, I checked on 2 other plesk servers I manage, and it's identical.

I appreciate any help / hints towards getting JIT to work.

Thanks!

 

[Sebahat.hadzhi]

If you are using Imunify, please double-check if the compatibility mode is enabled. Once enabled, you should no longer encounter the incompatibility error.

 

[JohnWest]

Ah I see,

So I added the line suggested to the /usr/share/i360-php-opts/module.ini


Then I did a restart of immunify service
systemctl restart imunify360-webshield

I also restarted the Dedicated PHP-FPM service for good measures.

JIT now shows as enabled!

May I suggest that Plesk auto-detect if immunify is running and does this modification to the config as part of the performance booster (when ticking the JIT) box, as I'm sure many people do enable it thinking it's working when in fact it isn't.

 

[JohnWest]

I did noticed that this only works with the Dedicated PHP-FFM by Apache. If using the non-dedicated one, JIT still doesn't enable for the same given error.
Any idea why ?

 

[JohnWest]

Also adding this here as it might help others

With my Dedicated PHP-FPM by Apache, if using opcache.jit=1235 I'm getting some 503 errors on my wordpress sites. Not all of them, just some... not sure why that is.
Resolution was to change it to opcache.jit=1254 or opcache.jit=1255 (1254 is what the performance booster uses by default, 1254 vs 1255 did not yield any noticeable performance benefits..)
If someone knows for 1235, I'd be curious to know why.

 

[ChristophRo]

Difference according to PHP manual:

0: Compile all functions on script load.
1: Compile functions on first execution.
2: Profile functions on first request and compile the hottest functions afterwards.
3: Profile on the fly and compile hot functions.
4: Currently unused.
5: Use tracing JIT. Profile on the fly and compile traces for hot code segments.

The "tracing" means that it will scan the script and only optimize/compile the parts that seem to benefit from it.

So with 1235 the whole script gets compiled by JIT, while with 1254/1255 it will only do parts of it.
Thus the later one has lower "overhead" and should result in a faster response time on the very first request of that script/file.
The 1235 option could result in more speed on consecutive requests though, in case the tracing function did miss a part that would have benefited from JIT compiling.


As for the 503 errors...
It's a common theme with the JIT compiler of PHP and may also randomly happen with 1254/1255
Nobody seems to really know why, but lots of people are complaining.

We also tried the JIT compiler (with 1254) on several of our servers (for thousands of websites) a while back, but reverted that decision after a couple weeks.
The sporadic and unexplainable 503 errors and the weak performance gain in general made the decision easy in the end.
We also had some sites, that got considerably slower (25% and more) with enabled JIT...so why even bother?

 

[JohnWest]

Yeah, I think you recap very well the situation. For anyone hosting WordPress, there isn't much or no gain at all from enabling JIT.
And it has more possible drawbacks (503 discussion) than advantages.

If you are after speed, the clear winner for TTFB reduction on any WordPress site still is pure CPU speed. Switch to the likes of 3.7GHz dedicated cores for example vs using vcores-type hosts, and then look at the rest. These vCores suck ... it's garbage compute. Adding more isn't a solution for PHP single page execution, it will only help for handling more "slow" visits.
The few $ of extra hosting is worth all the hours spent trying to optimize for things that will only gain you a few ms at best. (if you can afford it, it's generally a 10x in price)

While we talk about performance gains, I did find a better config for opcache than the one that comes with the speed booster (recommended use on a dedicated PHP-FMP by apache) - Main issue with the out of the box config is that there isn't enough memory for opcache and too little files, so you never get 100% hit.

Standard speed booster config is:
opcache.huge_code_pages=1
opcache.interned_strings_buffer=64
opcache.jit=1254
opcache.jit_buffer_size=32M
opcache.max_accelerated_files=1000
opcache.max_wasted_percentage=15
opcache.memory_consumption=128
opcache.revalidate_path=0


My suggested (100% hit rate) + faster TTFB config : (my WordPress here is relatively large with jetengine, WMPL type stuff on it)
opcache.huge_code_pages=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=10000
opcache.max_wasted_percentage=5
opcache.memory_consumption=1024
opcache.revalidate_path=0
opcache.validate_timestamps=1
opcache.revalidate_freq=10

opcache.enable_cli=1
opcache.use_cwd=1
opcache.jit_buffer_size=32M
opcache.jit=1254


The gains of using a dedicated PHP-FPM is substantial tool.