Opened 4 months ago
Last modified 4 months ago
#16112 assigned Bug/Something is broken
Slow site
Reported by: | Steve Pierce | Owned by: | JaimeV |
---|---|---|---|
Priority: | Medium | Component: | Tech |
Keywords: | Cc: | pierce@…, rogermanningnyc@…, mm@… | |
Sensitive: | no |
Description
We've received many reports over the past few weeks that www.mediasanctuary.org is responding very slowly, at times not at all. We're not sure why this would be happening. Would it be possible to look into this for us?
Change History (11)
comment:1 Changed 4 months ago by
Owner: | set to JaimeV |
---|---|
Status: | new → assigned |
comment:3 Changed 4 months ago by
BTW, I also asked Roger to take a look at the problem. This is what he found:
Ran all the WordPress updates. Let me if that helps at all. You-all have added a considerable number of complex plugins and that may have an effect on site performance. But looking at the error log and doing a bit more research the slowdown may be due to attacks on the site being warded off by WordPress. There are many instances of this error:
[Thu Nov 12 14:44:03.397611 2020] [access_compat:error] [pid 1471:tid 139663688709888] [client 204.197.178.82:50553] AH01797: client denied by server configuration: /home/members/nyma/sites/mediasanctuary.org/web/xmlrpc.php
I'll look into things more later today or tomorrow.
Roger
comment:4 Changed 4 months ago by
Cc: | rogermanningnyc@… mm@… added |
---|
comment:5 Changed 4 months ago by
I've made the switch to route mediasanctuary.org through our caching server. Let us know if over the next few hours you begin to notice any difference and please ask your team to test different parts of the site, submission forms etc... to help ensure everything continues working as it should.
comment:6 Changed 4 months ago by
I also want to point out something a little more basic.
The two largest files that have to be downloaded to load the homepage are these:
https://www.mediasanctuary.org/wp-content/uploads/2020/08/1.png
https://www.mediasanctuary.org/wp-content/uploads/2020/10/2.png
Together these are almost 5MB of file download for a homepage load. That is a lot and is sure to slow down you home page no matter what we do. You should really consider replacing these two files with more compressed jpg versions. You will see a big difference.
comment:8 Changed 4 months ago by
Thanks for the tip on the homepage images. We've replaced them with much smaller files.
We've been checking various site elements and working on page updates. The site is still V E R Y slow today!
comment:9 follow-up: 10 Changed 4 months ago by
hi JaimeV
1) Routing mediasanctuary.org through the caching server hasn't improved performance. Is it possible to return things to previous configuration? I'm thinking that makes testing other possible solutions simpler? (Ie: does caching server delay effects of changes made?)
2) Did you add the xmlrpc.php related edit in the advanced 'Web Configuration' on Nov 15th? I just went there to add a similar entry and see it's already been attempted. (Not having an effect).
3) Fwiw, checking the error log today I see over 5000 entries since Nov 5 of that xmlrpc.php related error mentioned previously.
thanks! Roger
comment:10 Changed 4 months ago by
Replying to https://id.mayfirst.org/mswp:
hi JaimeV
1) Routing mediasanctuary.org through the caching server hasn't improved performance. Is it possible to return things to previous configuration? I'm thinking that makes testing other possible solutions simpler? (Ie: does caching server delay effects of changes made?)
I will say that unless it is actively affecting functionality, if the caching server isn't making things faster it can't be making things worse. Yes, routing through the caching server might delay seeing the results of some changes. I will switch the DNS to point back to the origin server now.
When I run your site home page through several free website performance analyzers they seem to point out that many layers of css and javascript files are the first thing blocking the immediate page load. One reason you could have so many spearate css and javascript requests is because several wordpress plugins and the theme are inserting their own. These sites also point to large images that might be better resized or compressed as the next thing that is slwoing down page load.
In general the site appears to load between 5-6 seconds. Here are just a few of the tools I tried with.
https://gf.dev/website-audit https://tools.pingdom.com https://gtmetrix.com/
2) Did you add the xmlrpc.php related edit in the advanced 'Web Configuration' on Nov 15th? I just went there to add a similar entry and see it's already been attempted. (Not having an effect).
That change was already there and I think was added at an earlier date.
3) Fwiw, checking the error log today I see over 5000 entries since Nov 5 of that xmlrpc.php related error mentioned previously.
Every time access to that file is blocked it is logged as an error. That shouldn't have an impact on page load speed.
thanks! Roger
comment:11 Changed 4 months ago by
One reason you could have so many spearate css and javascript requests is because several wordpress plugins and the theme are inserting their own.
-- Yep, I've mentioned the possibility of plugin related issues and the team is working on reducing the number of plugins.
These sites also point to large images that might be better resized or compressed as the
next thing that is slwoing down page load.
-- The team has also been working on optimizing images.
r
Please login to add comments to this ticket.
Hi. Sorry for the delayed repsonse. I've looked into this and I don't see ny of the usual indications that the server where the site is hosted claudette has been under any stress. That doesn't mean your individual site has not been having trouble for some reason. I'm scanning the logs to see if anything is amiss. Can you tell us anything else about whether this is happening at particular times of the day? One thing we can do proactively is route the site through our nginx caching server which can really help speed up the site.
[update]
After scanning the logs I see one particular ip number has been hitting the site's login continously. It has been doing it just slow enough to not to trigger being blocked by our intrusion protection mechanism. Our nginx caching server also gives us a few more tools to limit this kind of behaviour. Would you like us to go forward with helping you make that change?