Open Vetpetmon opened 2 years ago
Reference: https://github.com/octfx/mediawiki-extension-WebP/issues/17
Most of the PHP lag actually comes from rendering images. Switching to Imagick did the trick, but we'd like to use the WebP format to further optimize. However, the guys managing the server did not put WebP support in Imagick, so if we are to use WebP, we have to move back to GD and use the WebP thumbnail extension. However, if you paid close attention, even after putting the server off of read-only for 5 minutes, thumbnails just did not work, they'd silently fail.
SNAZpedia will periodically switch between GD + WebP and Imagick for live testing. For now, Imagick has reduced CPU times from 1 second to ~0.140 seconds per page parse.
I am also looking into cache services, but I can't make promises. Getting Imagick with webp support was rejected, and probably so will my request for APCu.
Better cache methods are in place, and the server is optimized to the best of my ability. Active users will best notice the optimization, and so will anonymous users see the best performance.
WebP testing will still happen, as images are still a huge culprit for load times.
On average, it takes 5-9 seconds for PHP files (aka anything on the SNAZpedia) to load. This is actually not my fault, nor the server's fault. Rather, it is MediaWiki's structure and PHP itself that causes PHP slowdowns. Keep in mind that a ton of backend (SQL) work is additionally being performed that only I can see as your Server Guy.
I am going to invest in the long term for better server rack hardware later. For now, load times are not good, but they're not unbearable. We grabbed and use PHP litespeed, the fastest PHP distribution out there. I'm posting this issue so that everyone is aware that I've done everything I can to speed up the wiki.