Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Please be aware: Kaspersky Anti-Virus has been deprecatedWith the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.
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.
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.
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
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.
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.