Website outage after slow response

Website responding extremely slowly and sometimes gives Error 502 – Bad Gateway. Whoops, something went wrong at our end! Please try again later or contact us if the problem persists.

Error 504 – Gateway Timeout. The server timed-out handling your request due to a temporary overload or long-running script. Please try again later or contact us if the problem persists.

Please check and help.

  • Predrag Dubajic
    • Support

    Hi nusolutions ,

    I was doing some additional testing on your site and each time I visitied your site the CPU usage will jump to 100% and if this was happening with multiple users at once and for extended periods of time it would bring your site down.

    I wanted to perform a conflict test but I’m afraid that I was unable to because as soon as the plugins were disabled the site went in under construction mode.

    The load, of course, went down as well during that time, which suggests that there’s indeed something on your site causing the high CPU load.

    I also noticed in the activity tab that the issue started today when you had a higher number of visitors than usual, which means that the CPU load was running high for a longer time.

    At this moment it’s not clear if it’s a plugin or combination of plugins and you would need to perform a full conflict test in order to see where the cause is coming from, or use a higher plan so when the high number of visits happens again there will be more resources at your sites disposal.

    Best regards,
    Predrag

  • Predrag Dubajic
    • Support

    Hi nusolutions ,

    Your site is still experiencing high CPU usage and if you had multiple site visits at the same time ti could have bring your site down.

    I did another test by opening your site within multiple browsers at once and CPU usage pretty much skyrocketed right away.
    So if you have 3 or so people constantly on your site it will take on the resources and eventually stop the site from loading.

    I thought testing was being performed on your end to determine the cause of the high CPU load? Or that you could point me to the exact cause of the issue.

    We did do a general test which resulted in lower load, but since there’s a coming soon mode and almost 80 active plugins on your site the full test would need to be performed by you.
    We can help with troubleshooting to some degree but on the server end everything looks ok until the site starts eating up the resources and since each installation is unique based on plugins and theme running the tests need to be performed by the site owner.

    Best regards,
    Predrag

  • nusolutions
    • The Incredible Code Injector

    No disrespect but these are some very basic level responses you’re giving to troubleshoot a seemingly complex issue. If the answer to resolving this issue was as simple as this response I wouldn’t have needed to migrate my website to begin with. The expectation is for there to be a higher level of support provided than what I was receiving at my previous host. I expected a little more in terms of diagnosing & pinpointing theme or plugin related issues but if this the best I can expect then what’s the point.

    Thanks

  • Adam Czajczyk
    • Support Gorilla

    Hello nusolutions

    I’m sorry if that seems like too basic responses but WordPress is what it is – the problem is that there’s a lot of things that simply are not possible to fully track down and confirm without some “guess work” and experimenting. We can see certain things e.g. in logs of the site and/or server and draw some conclusions based on site behavior, logs, server stats and so on but in many cases it all comes down in the end to the need of testing things. It’s purely because of the fact how WordPress works – the (very limited, unfortunately) diagnosing tools it provides and the way all the possible code parts used on site (so various themes and plugins created by different developers, with different quality code, used in different combinations) are interacting with each other.

    I’m saying it only to explain why sometimes such “basic” responses – or rather “troubleshooting steps” – are unavoidable. Very often (I’d say: usually) it’s not really the “basic level” but rather first steps from which then we can “climb up” narrowing down the issues, “drilling” to the core of the problem and finding solution.

    Getting back to the issue though: I’ve just spent some time monitoring average server load for the site, while simultaneously browsing the site and running GTMetrix tests on it (just to put some load on the site). For the time being, the load did stay withing reasonable boundaries even though temporary CPU usage was jumping up to 100%, and the site was loading all the time without any significant delays.

    I’m not sure though if there were any significant changes made to the site meanwhile – were they? Such as, for example, some plugins disabled? Let me know, please.

    However, I have also noticed that following two plugins (actually three but I’ll get to it below) seem to be “troublesome” as events related to them are being constantly logged in in the slow log of the server:

    WiseChat and TranslatePress

    I suppose they are quite essential to the site but they also seem to be causing issues. Furthermore, both are “in context” and that “context” is the third plugin which is Domain Mapping.

    I tend towards saying that Domain Mapping might actually be one of the most important culprits here – probably not “alone” but I think it is very much related as there were already some performance issues reported regarding it in the past.

    The question is, though, if it is necessary for the setup. The plugin is no longer under active development and maintenance for quite some time already and the mapping is now WP core feature so in most cases – unless there are some very specific needs – WP doesn’t need any additional plugin for mapping custom domains to sub-sites.

    In my opinion aforementioned three plugins (with Domain Mapping being “on top”:wink: seem to be most “responsible” for causing additional load to the server. I’m not sure – as I don’t know the site that well as you do and I don’t know its needs/goals – if it’s possible to get rid of Domain Mapping plugin but it would be recommended to turn over to the WP core mapping and then, if performance issues are still a thing, checking alternatives for at least WiseChat.

    Kind regards,
    Adam

  • nusolutions
    • The Incredible Code Injector

    I had no idea the Domain Mapping plugin contributed to performance issues and was thinking of asking if there’s an update for it. I use it mainly to map sub-sites to custom domain names. If there’s a way to do this, map sub-sites to custom domain names, without having to use that plugin I’ll be glad to try it.
    Also, I’m up to over 100 alerts stating the site down and the same saying it’s back online. I check as these come in and in most cases the site is still online. If these are false how will I know when the server is actually offline?

  • Adam Czajczyk
    • Support Gorilla

    Hello nusolutions

    I use it mainly to map sub-sites to custom domain names. If there’s a way to do this, map sub-sites to custom domain names, without having to use that plugin I’ll be glad to try it.

    Yes, it’s possible now without using Domain Mapping plugin. Mapping is already a part of WordPress core, though there are some differences – it’s more “basic” than what Domain Mapping plugin was providing. For example, you can map only one custom domain to each sub-site instead of multiple ones and you can’t exclude parts of the sub-site from mapping. But those were the features that weren’t used often by most Domain Mapping plugin users anyway.

    As for how to do this:

    Since you already got domains mapped via the plugin we can safely assume that domains themselves are already properly configured (there are pretty much the same requirements for domain configuration in case of Domain Mapping plugin and the core mapping). The only thing that needs to be done to map the domain in a “native” way (without the plugin) is to set that domain in sub-site settings. By this I mean

    “Network Admin -> Sites” page -> “Edit” option for selected sub-site.

    You’ll find there’s a “Site Address (URL)” option and that has to be edited to use that custom domain. In case it wasn’t fully working out of the box then, apart from – as usually – clearing all caches – also switch to “Settings” tab on the same “edit’ page and make sure that also “Siteurl” and “Home” options there got updated to that custom domain URL.

    Here’s also an article that explains core WP domain mapping nicely:

    https://wordpress.org/support/article/wordpress-multisite-domain-mapping/

    That’s all that’s needed. One additional thing to remember though, since you are currently using Domain Mapping plugin:

    you can turn over to “core” mapping “gradually”, site by site, to avoid any issues (like sites not accessible) and the best way to do it would be

    – first, remove mapping for given site from Domain Mapping plugin (so the site wouldn’t use custom domain)
    – then add mapping in a “core” way as explained above
    – then proceed with next site until you got all of them “switched” to core mapping
    – and only after that disable Domain Mapping plugin

    Also, I’m up to over 100 alerts stating the site down and the same saying it’s back online. I check as these come in and in most cases the site is still online. If these are false how will I know when the server is actually offline?

    That’s a bit different thing. I believe you’re referring to our own Uptime monitoring, right? It’s worth remembering that there are three usually “scenarios”:

    1) the site is indeed down

    2) the site is not down but it didn’t respond to Uptime check request within 30 seconds; that usually means that there are some performance issues (permanent or temporary; depends on how often Uptime check reports “timeout” as a reason)

    3) the site is no down but it doesn’t respond at all or it rejects Uptime checks – that usually is a different issue and most often is related to either host (but that wouldn’t be the case with WPMU DEV Hosting as we don’t block our own Uptime) or to some additional security tools on site (sometimes a firewall or similar solution can block/lockout requests); that’s something that would have to be investigated separately as well.

    When you check uptime reports in The Hub and hover over each reported “down time” it would show you a reason of why that was detected as down so that’s something that’s worth checking if there’s so many of those down times.

    Kind regards,
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.