Home > Foundation, Setup, SharePoint, SharePoint 2013, SharePoint Server 2013, Windows Server 2012 > SharePoint 2013 page loads takes a very long time

SharePoint 2013 page loads takes a very long time


Short version: Stopping the Distributed cache service gave me great performance! From 6.10 s to 79 ms

NFCx

Something is just a liiitle bit off…?

Long story: This is a bit of reality right here…
I was about to give up on one of my labb SharePoint 2013 Environments because it was so extremely slow all the time.
Warmup scripts, reloads, more memory, more CPU, stopping services, stopping search…nothing helped.

I had a constant loadtime of all aspx pages of 6+ seconds, 6.10-6.20 something. Even when the page was just loaded and I pressed F5 to reload, it still took 6.10 seconds.
This was an environment that gave you sensitive nerves…

So, after looking for any solution or more like looking for the little issue that caused this all day, I gave up more or less.
– CPU was at a maximum 40% on SQL, SharePoint cranked it up to 18%…
– Memory consumtion was at 25% of the 12GB SharePoint had…
– SQL was Lightning fast to all other SharePoint farms…
– Network utilization showed about 100Kbps at the most…

I scavenged the internet as usual and found nothing but the standard: add more memeory, add more CPU, stop services, stop search…
None of that helped and I had tried it all…

Then…when all hope was lost, I got on a call with my excellent SharePoint buddy Mattias Gutke, we talked about the issue, his server on a laptop with SSD disks showed 50-100ms loadtime of all pages, reload did nopt even produce a flicker…
Then as often happens, we came to discuss the Distributed cache service, what it did and why it was there and so on…I had already had a look at it but could not find any reason why a default cache would give me this lousy performance. Then, I had a look at the timestamp in the F12 Developer dashbord – Network tab – Start capturing. I saw the home.aspx load and it took the usual 6.10 seconds.
The timestamp could be found in the detailed view and on the response header.
I memorized the timestamp (that was in GMT timezone) and opened up my ULS log. In the log at the exact time of the response header, I saw errors from the distributed cache.

ULS1

I decided that t-shooting the distributed cache would have to wait, it was getting late…but, before disconnecting the Lync call with Mattias, we decided to try and see just what would happen if I stopped the distributed cache service and loaded the page.
Said and done:

CA1x

Now, loaded the same site:

F12-2x

Whit the Distributed cache service running:

F12-1x

Notice any difference? Now my SharePoint farm is Lightning fast!!! From 6.10 seconds down to 79 ms!

Why is this so then you ask? No idea, something misconfigured or perhaps this is standard when using a single SharePoint server…anyway, today I don’t care.
Stop the service and the performance is great!

Hope this may help you as it did me!

Thanks to:

Mattias Gutke at CAG. Again, my SharePoint sparring partner no 1…


___________________________________________________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

Advertisements
  1. May 16, 2013 at 07:02

    Disabling the disty cache should never be a knee-jerk reaction though! Not even on a dev environment. It would be interesting to see the stack trace of those excptions in the ULS?!

    • May 20, 2013 at 20:26

      Anders, hardly a knee jerk reaktion 🙂
      ‘Warmup scripts, reloads, more memory, more CPU, stopping services, stopping search…nothing helped…’
      I spent hours, I could have coosen to spend yet more hours or days on t-shooting but I did not feel like it this time…
      I still have the logs though…
      Regards // Thomas

  2. Karl
    May 16, 2013 at 09:25

    nice trick, done it. witnessed it – performance increased. thanks!

  3. Sreeni
    June 19, 2013 at 23:09

    Thank you. This saved many days worth of troubleshooting with Microsoft Support

    • June 19, 2013 at 23:15

      NP. You should however try to find the root cause and fix it, if performance is restored and it is a production environemnt, you would want to have the distributed cache functionality restored. Some features will not even work without it.
      But, you are welcome!
      Regards // Thomas

  4. T. Montague
    September 12, 2013 at 15:11

    Marked improvement! Can’t even imagine how much time I just saved trying to ‘tune’ SP2013 to improve the otherwise painfully slow responsiveness! Thank you!!

  5. M
    September 14, 2013 at 17:36

    Thanks, works like a charm. Thanks 2 for Mattias Gutke at CAG. Again, my SharePoint sparring partner no 1…

  6. September 25, 2013 at 08:46

    I think, stopping Distributed Cache is not a solution! Additionally, there will be a lot of unexpected ULS logs regarding to Distributed Cache. Investigate under which account the given service is running and create for that account a managed account. Then restart Distributed Cache service.
    This help me decrease response from 6000 ms to 200 ms.

    • September 25, 2013 at 08:53

      Hi.
      Thanks for your feedback.
      You are right, in a production environment or test when you rely on The DC service.
      But, in test/lab when you only want to get things going fast…stop does do the trick 9 out of 10.
      If you read the entire post, I do not say stopping it is the solution…😃

      Regards
      // Thomas

    • September 25, 2013 at 08:57

      Hi again.
      To prove that I agree 😃
      Locate my post named ‘How to: Change the Distributed Cache Service managed account 2013’ that I wrote a very long time ago…
      Could not get the link in, using the phone…

      Regards
      // Thomas

  7. Gareth
    October 15, 2013 at 21:19

    Thanks for this – it sorted out my performance dramatically. I found the culprit by removing the DC Service from all machines in the farm using Remove-SPDistributedCacheServiceInstance
    , except one and then moved the services one to each of the other servers, one at a time, until performance dropped off.
    Cheers
    Gareth

  8. November 18, 2013 at 23:53

    My god! It’s sooooo fast now. Thanks ever so much!

    • November 19, 2013 at 12:34

      🙂 As it should be even with the DC running, my advice, try to figure out why it failed Before and fix it. Some Components require it to be running.
      Regards
      // Thomas

  9. Roushan
    November 23, 2013 at 15:14

    Great help, thanks, Disabling distributed cache did work.

  10. Josh
    January 4, 2014 at 03:25

    SO FYI for anyone having SharePoint Performance issues. I found something over the course of dealing with a client who had a huge performance drop in site load time. I was stumped for some time. I found one thing that seemed to help with load time which was enabling BLOB Cache which many articles will talk about. This will pull files that you choose such as jpg and store them locally on the SharePoint server. If you have multiple WFE servers this could possibly cause a problem as this Cache won’t clear out until you force it out. So a nightly script or hourly script depending on the load of the servers could clear this data if these items are changing throughout the day. For my situation it doesn’t change much at all. Next the biggest thing that helped me that I could not find an answer on the internet was in IIS. But, In the application pools area. I reviewed all settings and noticed that the “Recycling…” configuration was set for “After every 10 transactions” it would recycle the AppPool automatically. This was my culprit. After modifying this setting to recycle every 1 hour of the day which very well maybe still excessive will boost your SharePoint performance drastically. I am getting pages to load now in under 1 second. I don’t have a huge amount of users logging in, but just if it helps someone else over come this problem I’m glad I was able to Help!

    • January 8, 2014 at 09:06

      Recycling your application pool every 1 hour is totally unnecessary unless you got some custom code with memory leaks! Essentially what you do is that you throw off every single user that has a session on the WFE off the server. If I was the user on that farm I would be very unhappy with that solution 🙂 If you have memory issues you can consider setting Specific time(s) to a time of day where you have no or few users, but in general the App Pool will recycle by itself if it uses excessive amounts of RAM. Who ever set the Fixed # of requests clearly did not have a clue how that affects performance and end users on the server…

      • January 8, 2014 at 12:10

        I agree 100% with Anders.
        In addition, you would probably need to run a wakeup script after each recycle to avoid an uproar among the users….

      • Josh
        January 8, 2014 at 14:42

        Thanks for the update. The SharePoint solution is not being used consistently by all users throughout the day. For now there are only a few users who are using it as production. Eventually it will be their all-in-one solution for most of the business except their ERP system. I’m only dealing with about 70 users or so. But thought it was interesting that someone set that parameter for 10 transactions to recycle the app pool. We have custom programming in SharePoint for web parts, but nothing extreme that is causing the AppPool to fail or act different then before. I will update the system to recycle in the early morning. Thanks for the tip. I wasn’t quite sure what the “Recommended” setting was for the AppPool.

  11. Hubertus
    January 8, 2014 at 15:40

    Would be interesting to know why the problem appears and how to solve it properly!!

  12. Aaron
    January 10, 2014 at 19:57

    If you need to remove a server from the Cache Cluster, the safe way to do this is first to use Stop-SPDistributedCacheServiceInstance with the –Graceful parameter. This transfers any cached data to another server, and can therefore take some time to perform. Afterwards you can safely run Remove-SPDistributedCacheServiceInstance to make the current server a non-Cache Host.

  13. February 21, 2014 at 11:40

    I did it too. My goodness, Sharepoint 2013 finally works!

    • February 21, 2014 at 11:50

      Hi.
      Its great isn’t it? If its production, try to fix the underlying issue as well. DC is required for some services in SP2013.
      But short term, this usually does the trick.
      Regards
      // Thomas

  14. Kevin S
    February 26, 2014 at 21:12

    Thomas you keep saying try to fix the underlying issue – do you or anyone else know what the underlying issue would be for a SP 2013 Server configured with all the proper specs to be so slow with DC turned on? And fast when turned off? Turning off is 100% faster. Thx.

    • February 27, 2014 at 10:41

      Hi Kevin.
      The times I have had this issue and successfully fixed it, it was the service accounts on the DC service.
      But it can probably be a number of things causing it, the ULS log may tell you a lot about what the root cause is, in its own way…

      Regards
      // Thomas

  15. Bob
    May 9, 2014 at 10:09

    I didn’t want to stop the Distributed Cache service so I went with your suggestion of running it with a different managed account and this seems to have done the trick. SharePoint pages now load much faster. Thanks!

  16. September 4, 2014 at 20:47

    very useful , Thanks 🙂

  17. November 26, 2014 at 01:35

    I have read a bunch of docs of Microsoft about sharepoint 2013 and the solution is on a wordpress blog 🙂
    Thank you very much

  18. Manuel
    February 11, 2015 at 14:26

    thank!! that work

  19. Angelo
    April 21, 2015 at 08:16

    it works! thank you very much.
    i applied on my test farm composed by a single machine

  20. Mahmoud
    June 3, 2015 at 15:05

    Excellent post, thanks!

  21. August 22, 2015 at 23:12

    I did try this on my test environment and in deed the time load dropped, thank you.

  1. June 21, 2013 at 11:40
  2. November 27, 2013 at 11:18
  3. April 26, 2015 at 13:10

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: