Question WordPress Multi-sites slow - single WordPress sites fine. ideas?

[Matt N]

Hi All,

looking for a bit of a feedback here on what else to be looking at to resolve my issue. Apologies for the length of the post, but want to be sure that I've included all the pertinent details


first - a bit of server detail:

OS            : CentOS Linux release 7.6.1810 (Core)
Plesk Version : Plesk Onyx Version 17.8.11 Update #34
RAM           : 8gb
CPU           : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (8 core(s))
CPU Usage     : load average: 0.54, 0.90, 0.94    ** This is a "normal" day

We don't oversell our servers at all. On this particular server, we have a number of WordPress sites (running a mix of versions of WordPress - Mostly 4.7+, upto 5.0.2).

Single WordPress installs are exceptionally responsive, returning sites within 1 second (in their entirety). However, we have a few WordPress Mult-site installs (details below) which seem to suffer extreme performance issues.

WordPress Multi-site installs are all configured as "sub-domain" installs, in the root of the main site. One of the WordPress Multi-site installs is using different FQDN's for each site, and while the sites load, they are incredibly slow to "process" the initial work.

Note that the TTFB for the site is usually around the 30-40ms mark, but then WordPress takes (in some cases upto 15 seconds!) to deliver the site.

Examples of multi-site configs....

WordPress Multi-site 1 setup:

WordPress Version : 5.0.2
Multi-site setup  : sub-domain
Main site         : www.example.com
sub-sites         : blog.example.com, support.example.com
Default Theme     : The7 by Dream-Theme (https://the7.io/)
Cache Plug-in     : W3 Total Cache 0.9.7 (same performance with plugin-removed)

inside Plesk for this site, we have the following set up :

Main site - www.example.com - Plesk hosting settings
Domain Name       : www.example.com
Document Root     : /httpdocs
Hosting Type      : Website
Preferred Domain  : none (ie: no www.example.com, nor example.com)
SSL/TLS support   : yes
Perm. 301 HTTP>S  : yes
Certificate       : Let's Encrypt Wildcard for example.com (generated by Plesk plugin)
PHP Version       : 7.2.13 running PHP as FPM application served by nginx
CGI support       : no
Perl support      : no
FastCGI support   : no

Main site - www.example.com - Plesk Apache & nginx settings
MIME types        : default
Handler           : default
Deny Access...    : default
Index files       : default
Expires           : Custom value - 7 days
                  : Response with Expires headers for static files only = yes
Additional Headers: default

nginx settings
proxy mode        : yes
smart static files: yes
Serve Status files: ac3 avi bmp bz2 css cue dat doc docx dts eot exe 
                  : flv gif gz htm html ico img iso jpeg jpg js mkv 
                  : mp3 mp4 mpeg mpg ogg pdf png ppt pptx qt rar rm svg 
                  : swf tar tgz ttf txt wav woff woff2 xls xlsx zip webp

nginx caching     : Enabled
Cache size        : 128 MB
Cache Timeout     : 30 minutes
Cache key         : $scheme$request_method$host$request_uri

Bypass cache when : HTTP no-cache headers are received in request
                  : HTTP authorization headers are received in request
                  : GET nocache parameter in received in request
Return Stale      : Upstream returns 5xx server error
                  : Cache is being updated

Additional nginx directives:
if (!-e $request_filename) {
    set $test P;
}
if ($uri !~ ^/(plesk-stat|webstat|webstat-ssl|ftpstat|anon_ftpstat|awstats-icon|internal-nginx-static-location)) {
    set $test "${test}C";
}
if ($test = PC) {
    rewrite ^/(.*)$ /index.php?$1;
}

############
# W3 Total Cache nginx Config
############

include /var/www/vhosts/example.com/httpdocs/nginx.conf;

sub-sites - *.example.com - Plesk hosting settings
Domain Name       : *.example.com
Document Root     : /httpdocs
Hosting Type      : Website

SSL/TLS support   : yes
Perm. 301 HTTP>S  : yes
Certificate       : Let's Encrypt Wildcard for example.com (generated by Plesk plugin)
PHP Version       : 7.2.13 running PHP as FPM application served by nginx
CGI support       : no
Perl support      : no
FastCGI support   : no

sub sites - *.example.com - Plesk Apache & nginx settings
MIME types        : default
Handler           : default
Deny Access...    : default
Index files       : default
Expires           : Custom value - 7 days
                  : Response with Expires headers for static files only = yes
Additional Headers: Custom
                  : Strict-Transport-Security: max-age=31536000; preload

nginx settings
proxy mode        : yes
smart static files: yes
Serve Status files: ac3 avi bmp bz2 css cue dat doc docx dts eot exe 
                  : flv gif gz htm html ico img iso jpeg jpg js mkv 
                  : mp3 mp4 mpeg mpg ogg pdf png ppt pptx qt rar rm svg 
                  : swf tar tgz ttf txt wav woff woff2 xls xlsx zip webp

nginx caching     : Enabled
Cache size        : 128 MB
Cache Timeout     : 30 minutes
Cache key         : $scheme$request_method$host$request_uri

Bypass cache when : HTTP no-cache headers are received in request
                  : HTTP authorization headers are received in request
                  : GET nocache parameter in received in request
Return Stale      : Upstream returns 5xx server error
                  : Cache is being updated

Additional nginx directives:
if (!-e $request_filename) {
    set $test P;
}
if ($uri !~ ^/(plesk-stat|webstat|webstat-ssl|ftpstat|anon_ftpstat|awstats-icon|internal-nginx-static-location)) {
    set $test "${test}C";
}
if ($test = PC) {
    rewrite ^/(.*)$ /index.php?$1;
}

############
# W3 Total Cache nginx Config
############

include /var/www/vhosts/example.com/httpdocs/nginx.conf;

Here is a portion of my WP config related to Multi-site

define('WP_DEBUG', false);


/**
 * For Multi-Site network configuration
 *
 * Below configuration is designed for "Sub-domain" type network
 *
 */

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'www.example.com');
define('PATH_CURRENT_SITE',       '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
define('NOBLOGREDIRECT', 'https://www.example.com');
define('WP_DEFAULT_THEME', 'dt-the7');


/**
 * Cookie Mangement
 *
 * set's cookie domain to null, so that coookies can traverse
 * multiple sites in the network.
 *
 */


#define('ADMIN_COOKIE_PATH', '');
#define('COOKIE_DOMAIN', '');
#define('COOKIEPATH', '');
#define('SITECOOKIEPATH', '');

define('FORCE_SSL_ADMIN', true);


/* That's all, stop editing! Happy blogging. */

The second WordPress Multi-site we have installed pretty much follows the exact same configuration, except :

• sites are individual sites, with different URL's
• each site uses different themes

I can provide details of these, if need be.


As mentioned above, other Wordpress sites on the exact same server are able to return a fully processed site in less than a second.

We have another wordpress site, using the The7 theme - with is a standalone WordPress install, that returns a site (of over 4Mb for the home page, because the customer wanted a stack of images), and it loads in about 1.2 seconds.

We have confirmed the load times and performance, from multiple networks (to rule out and DNS/networking issues on our network at home-office) as well as from mobile phone services.

Again, TTFB is usually fairly fast (although running the tests in the Plesk KB Troubleshooting slow websites

Gzip is enabled globally - as per Plesk KB 213380049 How to enable gzip compression for nginx on Plesk server

I am open to any suggestions anyone has to improving performance ...

As mentioned, this is ONLY an issue for the MultiSite installs.

 

[MisterM74]

Hello Matt N
Ek was in die dieselfde probleme as jy oor die probleem van skrif op URL'e met Wordpress, is dan met 'n soektog op Google ek uiteindelik gevind via hierdie adres:
Running A Plesk Webspace Via NGINX And PHP 7 FPM
As jy volg die 3 funksies om brief, jou site sal werk, ek het die toets op my kant via die nuwe weergawe van Plesk onder Ubuntu 18.04 en dit werk.
Goed vir jou
Gelukkige nuwe jaar
Mz

 

[mmyeah-at-pm-dot-me]

Hi Matt,
How are you going with this issue?

I have current experience in optimising multisite environments and available to troubleshoot. There are a number of possible actions to get your ms tuned up and firing on all cylinders.

The performance issue would be less likely to do with Plesk (ie the areas already covered off above with stack performance); but more to do with WP itself, and the way it behaves.

The good news is there are a variety of ways to boost and optimise the WP core, by changing the way it behaves; so it suits you as webmaster; where WPMS responds how you wish.

Single-site installs often achieve expected results.

As multisite is a compromise technology, webmasters commonly report their ms installs as under-performing.

The fixes (and expected pitfalls) are not so well documented, as there are a number of commercial interests that promote ms plugins as a silver bullet to webmasters who seek 'simplicity'.

While there are a number of solutions to optimise any multisite, not all of the approaches play well with every plugin that the ms plugin promoting companies may have sold.

The commercial interests often keep webmasters in an uninformed state so they are intentionally unable to identify that it is the plugin systems (that have been sold to them) that are not performing as expected (under all circumstances).

It often takes a customised diagnosis because there are so many webmasters designing many different applications, including intended plugins, themes, and many resource contraints available to the webmasters. At least you have a good Plesk stack that can enhance a solution.

The planning and consultation aspect is often suppressed in the marketplace and left for consultants to tweak after problems have occurred.

As a result careful multisite design is 'under-informed in the market'. There are not many forums that deal with the multisite issue from a systems process aspect, or sites that properly inform ms users of the reasonably easy actions that can be taken to ensure ms projects perform.

The onus should be on the 'commercial interests that sell libraries of ms plugins' to better inform users before users implement their multisite plans.

I do not have the time to develop a comprehensive authority site on ms management, but able to assist issue by issue. The goalposts keep moving in the ms field; with the advent of new plugin technologies (designed for single site use), so over time the principles of ms management changes.

MS plugin pack producers that downplaying MS's fallibility: protects the companies that attempt to put a spin on, and hustle MS as a 'silver bullet'.... and deceives from consumer webmasters the reality of likely support services expected after implementing a ms under a generalised protocol.

The different optimisation protocols depends on what you aim to provide as a solution and product for your customers. What themes and plugins you depend on in final production.

You can get your WP multisites back in your control, have a balance of plugins, and be able to spin up differently configured, and high performing multisites.

First it would be helpful to know if your ms is still slow at present?

Let me know,
Best,
Jakob

 

[Bitpalast]

I can only say that this is not a web server issue, but purely a Wordpress issue. I think that the first place to start looking into it is to analyze what the actual requests are that are sent when a multisite domain is opened. It could be for example that the domain without https and without www is requested and first of all causing two redirects to the https and www version. Anyway, you will need a Wordpress professional for a solution, not a Plesk person. When the web server responds timely for a single site, it does the same for the multisite installation.

 

[mmyeah-at-pm-dot-me]

Peter has valid points.

There can be a number of other aspects over and above request-burden to do with WP.

Stack topology can be a major factor if you are trying to do a webfarm / wordpress.com sized mega-multisite on one install, but sounds unlikely.

If that is the case, then that, in that exceptionally limited circumstance; could be well beyond what Plesk is designed to do in the sense of specialised complex topograhic design with isolated servers. MS at scale needs very special server considerations and a different approach compared to high availability and scalable single sites.

On that note, about advanced stackology, one very quick bandaid you could apply, that comes from megamultisite best practice may be if you can clone the multisite server instance, with lsyncd file synchronisation, across 3 replications, under a round robin load balancer; and set up crons to shut down the master application server stack, and booting up a substitute (with one interstitial stack as slave). In this pattern, one stack is master perhaps for about 3 hours, and then shut down for at least 10 minutes to unthread its ram and go cold. A second stack takes over seamlessly, with a third as replicant. After a period of shut down with the first server, it then goes to the back of the service queue, and becomes the third replicant and updates files under synchronicity. If you are able to wrangle this, then it would most likely provide a sudden improvement in speed. Alternatively, you could take the server offline over night for 10 minutes and sample the ram anayzer. If you have got a performance boost then resetting the server for 10 mins every night *might* help. The shutdowns generally need to be no more than 3 hourly (as a solution) on a low demand server if there are significant variations in plugins and the number of db queries, writes to disc etc.

Here is a pic of a ram analyzer in a ms that I have begun to optimise...You can see the ram useage slowly increases significantly over time, even with just one admin on the site. After the shut down, the ram use drops down to less than 100mb for ms! This process in preparing the design and testing of ms prior it goes into production (as a template), is cyclical in optimising the theme and plugin configurations in order to get that ram use down, and where the memory demand can be as consistently low as possible. With traffic sent to the site, a ram hungry config will either crash it and fry the stack if exceeds max capacity, slow it to a crawl. Traffic would just cause MPMS to scoff more and more ram unless diligently optimized before going into production. Autoscaling servers wont help, when there is a ram jam. It needs transfer to a more complex stack with percona / mongo and redis, haproxy and memcached articulation, and that is just a waste of resources. I comes down to optimising. WPMS can work well with nginx app server under most use cases.

MrM74 is valid in ensuring the appserver is swapped out to nginx if this is wanting.

However with a 15 second page load time, the addition of nginx may reduce page load by 3 seconds, and so the emphasis is on optimising wp.

It would be helpful to know the number of sites you are managing in ms as a starting point?

I'm happy to run sensitivity tests at my end on specific implementation factors pro bono. As this would involve discussing plugins then it would be better done off forum, and you can hit me up by translating my membername into a usable address.

Best,
Jakob