so a site I'm working on (derwentvalleytasmania.org.au) which is live during editing, is having HEAPS of trouble loading quickly. GTmetrix shows 1.7sec load time, which is fine, but then when I actually try to load the site it takes anywhere from 15-30 seconds - the page size is less than 1mb and the images are optimized, uses WP Rocket for Caching and Autoptimize - when I test with an actual browser (chrome, ie, firefox) it still takes 15-30 seconds to load.
Pingdom and google page speed insights tell me the server takes too long to respond, and the wait time ranges from 4 to 60+ seconds for a response - I use windows plesk deluxe hosting.
Any help appreciated!
Hi there @Nathano!
Thank you for posting. Looks like you were able to get this resolved. The site's loading quickly for me and pingdom is able to scan the site and provide results. It looks like they have just a couple of things to suggest for better performance.
There are a few things at play here. Assuming this is a shared hosting account and you are running Plesk. The main thing that I fail to see anyone from GD disclose is the application pool.
Here is a use case:
1. No one has visited the site in 5+ minutes. If you look at the application pool settings it is set to stop after 5 minutes on inactivity. Now say Bob goes to your site, your application pool has to fire up. During this time Microsoft does a few things, if the app is any sort of .asp app it will extract and update the temp dir cache (on you local machine you can see it at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files <change the version accordingly> and at X:\temp\appPools <this path is dependant on how IIS is configured>), allocate memory to the app pool, run any modules for that application pool (starting with site level down), then start work on loading your app. The catch to this is that this whole process will not exceed the max memory allocated by GD. Think of it as a governor for an engine to where no matter how much work it has to do it will only produce at X rate. Any subsequent request should see things working at the speed of your application as long as there isn't 5+ minutes of inactivity on that application pool.
2. With PHP applications under this the application pool still has to do sort of the same thing (minus extracting the cache) but because it is likely running as a MOD the fast-cgi module has to run all the way through and check system level authorizations.
*Depending on your plan you might get a boost but ultimately you are on a shared host. The caching your app does will not speed up the app pool if it were put to sleep. That is all infrastructure and QOS controlled.
All of this is so they can put X amount of accounts on a single server and Quality Of Service (QOS) the host itself. I do believe 13 seconds (what one of mine is hitting at for a simple 1 static page app) for the app pool to fire up is way too long and has me looking for another host after 14 years. I'm even willing to hop on over to AWS or Azure but our shared sites should not be loading at the speeds of AOL.
I'm sure some GD peep will come back at me and be like, that ain't what's going on. Well, senor rana, how provide useful information here so we can plan accordingly.
I wanted to provide some clarity about the application pool settings within our Plesk Shared Hosting Environment. @dzsoundnirvana is correct in stating that we currently have a 5 minute ‘idle timeout’ for Dedicated IIS Application Pools. We disclose all of the App Pool settings within the “Dedicated IIS Application Pool for Website link within your Plesk control panel.
The 5-minute idle timeout setting helps ensure resources are not consumed by websites that are not currently in use. This frees up resources for other websites that exist on the same shared host.
Based on our own metrics, and our customer feedback surveys, we fully acknowledge that there are opportunities to improve the performance of both the Plesk control panel and sites hosted on the platform. Our current priority is to complete the uplift of our entire environment to enable Plesk Onyx and features such as PHP 7.3 and ASP.net core (all coming soon).
@dzsoundnirvana, regarding your comment about the 13 second timeframe for the app pool to spin up, it is not expected and should not be occurring. One of our GD engineering peeps will be reaching out to you directly to get a better grasp of what may be going on.
@JesseW Thank you for the response and information.
I should have better stated about disclosing the 5 minute (or any amount) timeout when shopping for a GD solution. As you stated, it isn't until you get into the hosting controls that you see what constraints the shared hosting has in regards to IIS settings.
PHP 7.3 -
ASP.net core -
I will be waiting for someone to hit me up.