Extremely Slow WordPress Site, Works Fine on Other Servers

Description

I’m migrating a website from another web hosting company. It’s a WordPress site with about 200 requests on each page load, so that definitely needs to change and be optimized. It takes about 1-2 seconds normally for each page to load on a known good server (not good, I know, bear with me). When I migrated it to ApisCP, the site takes 15 seconds or more to load. Looking at the iostats the disk is hit hard.

The server that runs ApisCP has about 10 sites that are low traffic. The site I’m migrating is low-medium traffic. It’s sitting on a dedicated box, Rocky Linux, AMD EPYC 7642 4-core vCPU, 8 GB RAM. Other sites also feel slow.

When I load this site, it takes 15 seconds or more, and it bad enough where it kills my SSH connection and I have to reconnect, and then shows either 429 Too Many Requests or 503 Service Unavailable in the browser. Restarting php-fpm seems to resolve it, but then there’s also a shield in the mix that I’ve disabled temporarily for troubleshooting. If I migrate the site to my older shared VPS, it loads the same site in 1-2 seconds. So I don’t think it’s a hardware issue. It feels like ApisCP is limiting performance, or something.

I adjusted the max memory in PHP to 768M and increased the php-fpm max processes to 50. The site still has the same issue.

Other websites on the server also feel slow. Even a light WordPress site takes about 500-1000ms to load, whereas on another server it takes 100 ms.

I’ve checked many areas but am not sure what to do to troubleshoot this.

Environment

ApisCP version: cpcmd misc:cp-version

revision: 45fade15eb9c075fc4143fbb67f6dbab116538aa
timestamp: 1768180847
ver_maj: 3
ver_min: 2
ver_patch: 48
ver_pre: 41-g45fade15e-dirty
dirty: true
debug: false

Operating System: uname -r

Additional relevant information (e.g., PHP version, database, etc.):
4.18.0-553.89.1.el8_10.x86_64
MySQL
PHP 8.2.27

I appreciate your time in helping me solve this!

No artificial limits are imposed unless configured as such under the cgroup service. For a fair comparison you need to run the same HTTP stack. I would recommend installing xdebug on the site to profile. You may get away by running php index.php from the terminal directly.

There’s probably some form of caching that’s bypassing the need to make 200 individual requests. This manifests itself incorrectly as some artificial barrier imposed by ApisCP, which it is not doing any such thing.

I can have a look on your site and server (for free) DM me, if interested.

We’re using Apache, but our other server is using OpenLiteSpeed. OLS handles the site just fine with 200 requests on a shared server, but ApisCP with Apache does not and effectively bricks the server for a time.

OLS has caching baked into the HTTP stack. I’d recommend installing a caching plugin like W3TC, which affords similar fixtures without extra licensing overhead. If it’s coming from shared, it’s most likely licensed LiteSpeed for htaccess interoperability.

Documentation covers installing W3TC and tuning it. Advanced topics covering profiling and Redis are also available. Redis, I’ve not seen any benefit outside of logical caching for planner-heavy queries.

It’s important to compare like-to-like in these situations. Caching solves some issues but isn’t a solution for shitty code of which WP plugins are a dime a dozen.

Thanks for your reply. I already have a caching plugin installed, and the problem persists. I guess my concern is that, on another server with Apache, the website runs fine, and it’s a shared server. But my dedicated server with ApisCP runs slowly.

I’m considering switching over to LiteSpeed. Any recommendations on changeover?

Find the root cause. Solution is not litespeed.
DM me the site url and I can point you in right direction.

Switching to litespeed indirectly may solve your issue. But root issue will persist. Do it right way.

LiteSpeed is unsupported and unlikely to ever be supported. They produce a competing product, CyberPanel. This would be your best bet for a product directly sponsored by LiteSpeed.

Building a stack for a competing product is an invitation for a licensing rug pull, which we’ve seen with Redis and ElasticSearch.

I’d recommend stepping through the sample WordPress benchmark to evaluate how individual optimizations impact page loads as well as running through xdebug that may elucidate high latency network operations, which I have seen from time to time.

For what it’s worth, I think this is a hardware or configuration issue.
I have some old servers I’m phasing out that have better performance than what’s described here.
~200 accounts on a server and some of those accounts have very popular wordpress sites.
Never seen issues like this.

Servers in question:

2x Intel Xeon E5-2630v3 - 8c/16t - 2.4 GHz/3.2 GHz
128 GB ECC
2×1.92 TB SSD NVMe w/ Software RAID

Provisioned to 2x KVM VPS running AlmaLinux 8 with 48GB Ram to each VPS and 8 vCPU.

Definitely odd. Here’s why I was considering LiteSpeed. I’m currently using OpenLiteSpeed on another server, that is a shared VPS, and everything works fine.

Does AlmaLinux work better than Rocky Linux for this?

ApisCP server:

  • Dedicated VPS
  • 4 CPU Cores - AMD EPYC 7642 48-Core Processor - 2.3 GHz
  • 160 GB SSD Storage
  • 8 GB RAM - 2 GB / 8 GB being used
  • Hosts 10 websites
  • WordPress sites slow
  • When WordPress site is visited, it becomes so slow, it crashes my SSH connection.
  • This server was created 6 months ago

Current OLS server:

  • Shared VPS
  • 4 CPU Cores
  • 160 GB SSD Storage
  • 8 GB RAM - 5 GB / 8 GB being used
  • 4 CPU Cores - AMD EPYC 7713 64-Core Processor - 2 GHz
  • Hosts 40 websites
  • WordPress sites normal, after migrating site from ApisCP to this server, works fine.
  • This server was created 4-6 years ago

I use SolusVM for my Virtualization and they prefer AlmaLinux.
I worded my post wrong. The Physical server is AlmaLinux + SolusVM Slave.
The KVM VMs are Rocky Linux 8.x and run ApisCP.
I prefer Rocky for ApisCP. Two Years ago on Discord…

You’ll need a caching plugin that affords the same functionality as LiteSpeed. A good caching plugin will render the HTML to disk, then Apache will locate this file on disk and serve rather than loading 75+ WordPress plugins, which at even 100 ms overhead each is 7.5s overhead. Apache by itself is quite performant when like is compared to like (NGINX is a couple microseconds faster :person_shrugging:).

Benchmark.md covers this, as well as trimming .htaccess that can provide savings. LiteSpeed caches .htaccess (OLS requires restart for .htaccess rules to update, LiteSpeed does not). That’s something I wish Apache did, but it makes memory requirements lighter.

If you’re getting the same page load when caching is enabled versus disabled, then caching isn’t active. I’d dig deeper into why as you should have no issue putting out 20k rps on a site with full caching.