• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Poor wordpress database performance on Plesk server... any ideas?

That server configuration appears fine, but what MySQL or MariaDB versions are you using, and what Plesk version are you using?
 
I have the exact same issue. I use a VPS with 8 cores, 16GB RAM and the QPS is very lower than the cheapest GoDaddy shared hosting.
TS, did you manage to find a solution? This issue just drives me crazy.
 
also i have the same problem. plesk is clearly slowing down the database. did someone solve the problem?
 
I experienced with VPS that the SQL server was installed and shared on a completely different server.
Then everything (Plesk, Wordpress...) was very slow.
In addition, the SQL server was poorly configured in relation to Innodb.
 
I found a solution.

Webserver & PHP tune​



  • Use as latest PHP version as possible - there is steady tendency, that newer major PHP versions will execute same code more efficiently and faster.
  • Make sure, that opcache PHP extension is installed and active
  • If possible - switch to PHP-FPM, use either static or dynamic PHP-FPM pm-manager.
  • Make sure your webserver support HTTP/2 and offers either deflate, gzip or brotli compression. There are various online tools, which can check this for you, search for webpage compression test.
  • If you are using Apache - choose either mpm_event or mpm_worker.


CPU performance​

You should understand, that PHP is not multi-core processes, that means, that one PHP request utilize one CPU core. That means that speed of processing of one request does not depend on number of CPU cores, but more on single core performance and clock speed. My tests on different CPUs (both AMD and Intel) show, that clock speed makes more difference - therefore I suggest choosing CPU with higher clock speed. Quite often expnsive server CPUs with 32-64 CPU cores are clocked with lower MHz, than more desktop-grade CPUs.

Filesystem tuning​



  • Choose SSD hosting - this has become a standard - hardly any hosting company offers hosting on old spinning disks
  • Add noatime tag to filesystem mounting options in /etc/fstab - this will instruct Linux not to write time of the last access-time of the file.
  • Avoid using SWAP as much as possible. Add the following parameter to /etc/sysctl.conf to instruct kernel to get into SWAP as late as possible:vm.swappiness=0
  • Instruct Linux to write data onto disk in larger bulks and with a bit of delay - while this adds certain risk, it can greatly improve overall writing performance, especially for small files. Add similar values to /etc/systctl.conf:vm.dirty_ratio = 8
    vm.dirty_background_ratio = 4


MySQL database performance​



  • My suggest is to use MariaDB 10.3 or MariaDB 10.5, both with enabled query cache.
  • Some MySQL settings can do a lot difference, I list most critical ones:innodb_flush_log_at_trx_commit=2
    innodb_file_per_table=1
    innodb_thread_concurrency=0
    innodb_buffer_pool_size=4G
    innodb_buffer_pool_instances=8
    innodb_log_file_size=256M

    query_cache_type=1
    query_cache_limit=128K
    query_cache_size=64M
    query_cache_min_res_unit=512

    performance-schema=0

    sql-mode="NO_ENGINE_SUBSTITUTION"

  • Do not set innodb_buffer_pool_size or innodb_log_file_size too big. Also do not set query_cache_size higher than 128M or make proper tests, making sure it will not degrade performance.


Object cache & opcache​



  • Make sure you have opcache PHP extension installed and enabled.
  • If you have dedicated server for your Wordpress - install & use Redis for object cache. Full page cache with Redis also works great!
  • On shared hosting server you might want to try object cache using disk-based caching.
 
This is a copy of this page: Wordpress hosting benchmark

While there are some good suggestions in that article, it all depends on the type of applications your running, server hardware, etc.

Start with MySQLTuner on a server that is up for at least a couple of weeks and implement the suggestions one at a time. Wait a few days and implement the next one. Check if your server is getting better or worse. Try not to reboot the server in the meantime.

Important:
- don't run MySQLTuner on a server that has just been rebooted; the results will be useless.
- database tuning is complex. Don't do this unless you fully understand how this works.
 
Back
Top