How to optimize Virtualmin to host multiple WordPress sites with high traffic?

Hello everyone,

I’m currently hosting a few WordPress sites on a Virtualmin-enabled server, and some of them have started to experience a significant increase in traffic. I want to be sure the server is fully optimized to handle this spike without slowdown or downtime.

Can anyone advise on the best practices for optimizing Virtualmin specifically for high traffic WordPress sites? Primarily interested in server configuration for PHP and MySQL/MariaDB to improve performance and caching solutions (eg Redis or Memcached) and how to implement them in Virtualmin?
Maybe there are still some comments that I didn’t pay attention to.

Thanks in advance!

Not specific for WordPress but probably good for all high traffic VM:
(my highest traffic site uses a NodeJS app)

  1. consider having multiple cores (helps distribute processes)
  2. more physical memory
  3. I would also consider moving all Db on to a separate managed system (especially if the db is taking a lot of punishment)
  4. cannot help with caching - probably depends on how well the PHP is built
  5. probably also depends how mail is managed through PHP/your server (if at all)
2 Likes

W3C Total cache makes use of Redis or Memcache and can also configure all of your static file caching aswell as caching copies of dynamically created pages.

Redis is becoming closed source but I think there is an open alternative.

Redis is a lot more advanced than Memcache but is harder to setup.

Have a look at W3c Total Cache plugin and documentation, you might find this very helpful.

Also install Wordfence this will stop unwanted traffic.

1 Like

Unfortunately, I have no experience with splitting processes between cores on a server, are there any specific settings or tools I should use for this in Virtualmin?

According to me, it’s not related to virtualmin. It’s firt of all related to your application itself as stegan said. But being a wordpress a better server is probably the best bet, like he also said.

Still could you say first how much traffic are you getting ?

It’s hard to say if there is optimisation problems without knowing the amount of traffic. Sometime if the traffic is too high, as already said, the only solution is simply to get a new server.

But the question that @James_Bryant asked is “how to optimise Virtualmin for high traffic websites?”.

Does the community have an answer to this question?

@Stegan said that moving the database server from the Virtualmin server to another server (ideally also a Virtualmin) server would free up resources on the existing Virtualmin server and optimise it to serve web content. This is a pertinent answer to the question that has been asked.

He also suggests that mail and antispam services be moved to some other Virtualmin server to further optimise the existing server.

Another idea would be to take the RAM that has been feed up and utilise it as a cache to speed up the web and database servers. Bytecode cache is already part of the default Virtualmin installation. More RAM could be judiciously allocated to it.

These are the low hanging fruits for optimization. Are there any other tips and tricks that the Virtualmin community can offer in answer to the question of Virtualmin optimization as against WordPress optimization?

2 Likes

You are completely right when you said I didn’t bring an answer to the question. But It was not my intention.

I just would like to highlight that you can indeed try to make some optimisation at the Virtualmin level and get 20% better performance (And I’m even not sure you will get it because you have to take in consideration the price of each additional servers)

But at the opposite at the php level if you try to optimise from a bad architecture to a good one you will easily earn between 200% (2 Hundred) to 1000% (1 thousand) in performance (An I did heavy test on this part. Same for JS even if client side we have much more margin).

I just want to insist on this part. Because according to me (It’s my personal opinion) a good Dev should always try first to create a Great architecture better than expect the Cpanel to do it for him (What it is not plan for. A Cpanel is here to allow us to manage quickly; Not optimisation and even less architecture)

sorry for the delay on this specific question -

AFAIK none specifically.

the number of cores selected is (I think) dependent on the supplier of the VM (the box/bare metal) I believe it is above Virtualmin control and Virtualmin uses all the cores provided to the OS. (I have a couple of VMs set up with cheap single core set up - they are good for development, testing and low use websites but completely inadequate for production or higher activity. I was amazed at the move to just a 4 core.

1 Like

PHP


Note: The PHP settings can be set by domain, or by the “Server Template”. Depending on your requirements, one could me more practical than the other.
The Server Templates


Make sure to use FPM for PHP as it is the most efficient for RAM and speed (it uses long-living processes to run PHP scripts).
PHP Settings

Also see what FPM settings you can tweak to your requirements.
FPM Configs

I specifically like to tweak these:

  • Under Sessions settings: “Session storage mechanism”.
  • Under Resource Limits: “Maximum memory allocation”. The default could be too large, depending on the Virtualmin Plan settings…
  • Under Resource Limits: “Maximum execution time”. This frees up the CPU from buggy code that can get stuck.
  • Under Other Settings: “Compress output with zlib?” = No. Then use a reverse proxy (or a CDN) to do compression.

MariaDB
If/when the PHP server gets bombarded with requests, and the PHP settings aren’t adequate, it’s very likely MariaDB will be killed first by OOM.

The following is NOT a recommended solution. PHP and MariaDB settings must be planned according to the system’s capacity.
But still, to get MariaDB to restart automatically in such cases:

  • Run systemctl edit mariadb.service
  • Enter:
[Service]
Restart=always
RestartSec=16
  • Save and close the editor.
  • Run systemctl daemon-reload
1 Like

Thank you all for your comments! I brought a lot of things for myself!

2 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.