I think everybody knows that according to Windows Server 2012 default behaviour, all the application pools will recycle overnight. You can obviously tweak these setting but I think it is still a good practice to let the application pools recycle- weather based on fixed time intervals, memory or specific time.
This will have significant impact on how fast the SharePoint Server 2013 pages will load up first thing in the morning.
Since we operate in the UK and US (6 hours difference) and our system must be responsive more or less 24/7, we still had to think about a good time to let our pools recycle. We decided that 4 am UK time (10 pm US time) would be satisfactory, so I set that up in the IIS Manager.
A very good and neat script provided by Todd Klindt takes advantage of the new features in PowerShell v3 in SharePoint 2013 and takes warming-up SharePoint to just two lines of code:
Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object { Invoke-WebRequest $_.url -UseDefaultCredentials -UseBasicParsing }
In this example, Central Admin web application gets warmed up too.
Make sure you have a site collection in every Web Application otherwise the script will spit out some errors like in my case. It seemed to wake up the remaining Web Application (already populated with site collections) but my comparison results were not spectacular. Because I do not like red colour in my PowerShell window and I wanted to have an absolute certainty that this in fact works, I quickly created a host site collection in my MySite web application and the script ran OK. Now the users have a platform to create their personal sites (for which I also set up a quota of 2048MB) and take advantage of social features in SharePoint Server 2013. 'Quickly', because I have not finished provisioning of User Profiles Service Application as the process is complex and require a list of people from AD to which I do not have access yet.
[See details of how to accomplish this and step-by-step guide here. In addition, if you want other site collections in other web applications to be able to consume a User Profile Service Application used in My Site (enterprise wide social features e.g. hashtags), you have to connect each web application to that User Profile Service Application: see TechNet article outlining this].
My script to warm-up Sharepoint Server 2013 should run with no errors. It ran. Once. Then I was getting this annoying error after recycling my web applications again to further test the script:
Invoke-WebRequest : The remote server returned an error: (500) Internal Server
Error.
At line:1 char:41
+ Get-SPWebApplication | ForEach-Object { Invoke-WebRequest $_.url
-UseDefaultCred ...
I knew it is due to MySite web application that caused problems from the very start of our SharePoint 2013 installation. When navigating to the root site of this site collection in the browser- unexpected errors occurred so it must have caused more harm than good when running our script.
I deleted the My site host site collection because it was giving me more errors like 401 Unauthorised, 500 Internal Server Error.
I came back in the morning after pools have recycled, re-ran the script and I got this:
Invoke-WebRequest : HTTP/1.1 200 OK Server: Microsoft-IIS/8.0 Date: Fri, 05
Jul 2013 07:46:00 GMT Connection: close
At line:1 char:41
+ Get-SPWebApplication | ForEach-Object { Invoke-WebRequest $_.url
-UseDefaultCred ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:Htt
pWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe
ll.Commands.InvokeWebRequestCommand
The issue is currently with Todd Klindt on his blog. Maybe he can shed some light on what is actually wrong with the script and my configuration.
Just you know what are we even fighting for, here are some test results showing you how slow and how fast SharePoint Server 2013 can be when it is needed by e.g. most important people in the organisation.
Note: the results are not accurate to the every millisecond. Times are taken using a Stopwatch on the phone but are still very indicative.
Time needed to access 'cold' SharePoint 2013 root site after successful login:
Time needed to access 'warmed-up' SharePoint 20013 root site after successful login:
I think we all see that the matter is worth pursuing.
Since the script is not running 100% OK in our case, I will keep you updated on any fixing activities I may do (hopefully with some help from Todd Klindt).
EDITION- 30 JAN 2014
Finally got a working script here: SPWakeUp. You might want to run it as SP_Farm. I tried with an SP_Admin (daily administration of SharePoint) but it spat out couple of irrelevant, but annoying errors.
Schedule it with Task scheduler to tickle SharePoint sites in the morning and maybe every 15-20 minutes before pages go to sleep ;). Good luck.
No comments:
Post a Comment