Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Hosting Requirements /

What you need to consider when choosing a hosting provider and plan.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Experiencing very slow Latency / Waiting Time to First Byte on IIS hosting

Go to End

3 Posts   2080 Views


Community Member, 136 Posts

12 January 2017 at 1:05am

Hi all,
(Firstly, I had to setup on a client's pre-existing IIS shared hosting platform, so 'change to Linux' won't be a good answer here - even if it is ultimately the best solution)
The website & CMS are responding really slowly on this hosting. It can take anywhere from 10 - 30 seconds to do an initial page load. After that it has cached the pages and still takes over 4 seconds to process each page load.

The delay all appears to be with the ‘Latency’ or ‘Waiting TTFB (Time To First Byte)’ - not once the page actually starts to load (it’s very fast then).

The actual website pages are light. As a comparison test I uploaded a flat version of the same website (not linked to a database, no CMS) to the same server and it’s really fast.

So is this something to do with processing the Web.config or the initial connection to the database... or something? Any ideas?


Community Member, 67 Posts

12 January 2017 at 12:55pm

Not sure if you are already using it but you could look into partial caching which always improves the speed of the website.

It may also be worth mentioning what version of SilverStripe you are using and reviewing any database queries which are run when loading the pages.
SilverStripe does have some debug tools which can be called via URL variables which will give you some more info (debug_request and showqueries)


Community Member, 136 Posts

12 January 2017 at 10:35pm

Edited: 12/01/2017 10:37pm

Thanks for that Kirk
It's Framework & CMS version 3.4.1
I'm not sure that partial caching is going to help with the initial latency (TTFB) but I'll look into it.
I've tested it and it runs fine on an alternate linux hosting - which makes me think it has to do with something particular to the IIS hosting setup - I'll talk to the hosting guys about the PHP setup and see if something can be done there.

I've run debug and get the following info (which I think looks ok?)

Debug (Director::handleRequest() in Director.php:351)
sitemap.xml =
admin/cms =
admin =
Security//$Action/$ID/$OtherID =
CMSSecurity//$Action/$ID/$OtherID =
dev =
interactive =
InstallerTest//$Action/$ID/$OtherID =
JSTestRunner//$Action/$ID/$OtherID =
SapphireInfo//$Action/$ID/$OtherID =
SapphireREPL//$Action/$ID/$OtherID =
$URLSegment//$Action/$ID/$OtherID =
StaticExporter//$Action/$ID/$OtherID =
RebuildStaticCacheTask//$Action/$ID/$OtherID =
RemoveOrphanedPagesTask//$Action/$ID/$OtherID =
SiteTreeMaintenanceTask//$Action/$ID/$OtherID =
Debug (line 122 of ModelAsController.php): Using record #1 of type HomePage with link /

and debug_request returns:

Debug (line 250 of RequestHandler.php): Testing '$Action//$ID/$OtherID' with '' on HomePage_Controller

Debug (line 258 of RequestHandler.php): Rule '$Action//$ID/$OtherID' matched to action 'handleAction' on HomePage_Controller. Latest request params: array ( 'Action' => NULL, 'ID' => NULL, 'OtherID' => NULL, )

Debug (line 184 of RequestHandler.php): Action not set; using default action method name 'index'