7

I am facing a really bad SharePoint Performance since last week. It is noticeable if someone:

  • Creates new Subsites (takes ~ 3min.)
  • Edits document properties, press save (takes ~ 1min.)
  • Edits lists in Quickedit mode and press save (takes ~ 2min.)
  • Adding a Content Type to a library:

enter image description here

Things I did so far:

  1. Checked the Browsers Developer Tools (F12) in Network tab.
  2. Increased the Distributed Cache Size
  3. IIS reset
  4. ULS Viewer log live while creating new sub site
  5. Developer Dashboard is empty (Usage and Health is running)
  6. Deleted the recyle bin content (2. level)

Farm has 1 Application Server (32GB RAM, 4 Cores) and 1 Front-end (16GB RAM, 4 Cores) (here is Distributed Cache running).

SQL Server is not installed via Farm Configuration Wizard. Content Database isn't big. (~5GB)

The CPU and RAM usage is not high and also not increasing while creating or editing. I found those failed jobs:

  • User Profile Service Application - Feed Cache Repopulation Job
  • Delete Job History

But that can not be the problem, right?

Update:

Last week Kaspersky was installed on all servers. I know, not good, but that's the way it is. I stopped the program, but I has no effect. Is this maybe the problem?

Solution:

I uninstalled the Kaspersky Antivirus Software on all SharePoint Servers. Application, Frontend, Office Web Apps and SQL, rebooted all Servers and now I got my performance back.

Also the Developer Dashboard is now working (It happend to be empty (Usage and Health was running)). Thanks for all your help! Also thanks for the link Waqas Sarwar MCSE provided https://support.microsoft.com/en-us/kb/952167. I'll maybe try that if it has to be installed again.

  • Can you give us more about your configuration? CPU/RAM etc... – Seb Jul 8 '16 at 13:00
  • updated question. – Patrick Jul 8 '16 at 13:26
  • I know you were checking the ULS log during site creation, but are there any re-occurring errors throughout? Did the event log size spike around the time performance dipped? Is there anything in the event viewer? – David Jenkins Jul 8 '16 at 14:33
  • There is nothing specific in the event viewer which could be related to such an performance issue. – Patrick Jul 11 '16 at 11:50
  • @Patrick Updated answer – Benny Skogberg Jul 11 '16 at 16:27
1
+50

Your update:

Last week Kaspersky was installed on all servers. I know, not good, but that's the way it is. I stopped the program, but I has no effect. Is this maybe the problem?

has rung a bell!

I remembered I had such performance problems with a customer of mine. We disabled the anti-virus, and the problem remained (the same for you). But the problem actually vanished definitely when we uninstalled completely the anti-virus (+reboot the servers).

  • As I mentioned in Waqas Sarwar MCSE answer, I uninstalled KAV. Now I got my performance back. I might try the steps he provided, but for now, KAV won't be installed again. Also the Developer Dashboard is now working. Updated the question with the solution. – Patrick Jul 12 '16 at 6:16
3

Antivirus Always cause the issue. MSFT have the guideling regaring the AV. You ave to exclude the Certain folders from the AV scan.

  • Hive Folder
  • ULS Logs Folder
  • IIS virtual Direcotries
  • App / Local Fodler for the service account.
  • SharePoint Installed Location and more Please check Below KB for complete list of the exclusion.

Certain folders may have to be excluded from antivirus scanning when you use file-level antivirus software in SharePoint

  • I stopped the AV. But there is no difference. Is a server reboot required? – Patrick Jul 11 '16 at 11:27
  • stopped AV sometime not help, did you implement the Exclusion? also sometime uninstall the AV will give u performance back...on the side line, can you enabled the developerDashboard and check on which thing it is taking too much time? do you have AV On SQL completely disable it over there... – Waqas Sarwar MVP Jul 11 '16 at 14:00
  • The Developer Dashboard is empty (Usage and Health is running). AV will be uninstalled tonight, we'll see. – Patrick Jul 11 '16 at 14:53
1

Updated

There could be numerous of things causing this issue. Custom Code, Configuration issues in IIS such as the Application Pool or Firewall settings between servers. Before we do anything else, take backup of the SharePoint databases you care about, such as Content databases, MySite databases, User Profile Databases (if customized), Managed Metadata Service database, Search Service Databases (if you have configured Managed Properties) and all the rest where you know some configuration is done. If you have solutions in your farm, download those as well. If custom branding is performed, save those too.

  1. To start I would monitor Central Administration Website from the server it's running on. It should run on the App Server, but sometimes it can be on the Web Front End. It runs on a different web application but is still a SharePoint website. If it has equally poor loading times, you have serious Farm wide errors. But if the Central Admin responds quickly (less then a second) when you have filled your different caches, it's a good sign.

  2. Assuming Central Admin is OK, I would create a new Web Application (with a new Application Pool with another App Pool Account than the failing one). Create a new Team Site Site Collection. This rules out any errors with the Web Front End itself. When you hit your brand new Team Site a couple of times, it should also respond less than a second.

  3. Assuming your brand new Team Site is OK, we've narrowed it down to your Web Application, which is good. Now here things start to get interesting. Before doing this, make sure you have a backup of the content database. When you do we should copy the failing site collection to our brand new team site, to see if the new web app and site collection works better in its new location. Also make sure you don't crawl this new web app (it would confuse users have the same document in two different locations). Now run Backup-SPSite cmdlet with PowerShell Backup-SPSite http://theFailingSiteURL -Path C:\Backup\site_name.bak and then Restore-SPSite Restore-SPSite http://theNewTeamSiteURL -Path C:\Backup\site_name.bak. You may run into trouble restoring the site, and you may have to delete your new Team Site, but that's OK. Now we don't have any solutions implemented, and we shouldn't at this stage. Test your restored site and see what you got. Responding in less than a second after a few trials? If that's the case, you know you have errors in your old webapp or your custom solutions.

  4. Deploy the solutions and activate features the same way as your old webapp. Monitor traffic and see if you have issues or not. If you're OK here in your new web app, you need to plan for a switch to the new webapp.

Let me know the result when you get this far, and make sure you keep a close eye on the ULS logs and Event Viewer.

Outdated Answer

In these cases I'd recommend looking at the SQL Server. What's the memory utilization showing when you create a sub site? Do you have long running transactions (see SQL Profiler). Is you LOG-disk full (or almost full)?

  • LOG-disk is fine. Sadly, the log of SQL Profiler is nothing I have an idea of... – Patrick Jul 8 '16 at 13:28
  • Do you have maintenance plan on SQL? Is Fragmentation heavy? – Seb Jul 11 '16 at 9:18
  • Fragmentation seems to be ok – Patrick Jul 11 '16 at 11:27
0

I read that you increased the Distributed Cache size. I had a performance drop and the solution was to STOP/START the Distributed Cache on the Service on Server page in CA. Maybe it will work for you.

0

What are the developer tools (F12) telling you? What is taking so much to load? If images as an example are loading super fast but htmls have a long TTFB it is your app server and not front server issue, please give out more information.

How do you configure the crawls? What are the servers telling you? (Performance wise, track this).

Looks like your structure and the amount of queries is what is diminishing your farm performance, probably structured navigation is also adding due to the complex subsite structure and constant crawling per site load.

Please complement your question, it is very vague and you say "done this done that" but you don't show any results.

  • updated the question with an picture – Patrick Jul 11 '16 at 15:13
  • That's an html right? How about the other content? .JS, images and of the sort? Also, how complex is the navigation structure you've created? Do you have a lot of sub-sites under sub-sites? Are the initial minutes you've averaged chronometered or just on your feel on how long it takes? – Yugo Jul 11 '16 at 15:15
  • everything else is in the milliseconds range. – Patrick Jul 11 '16 at 15:16
  • Ok so it's not the front-end server the one with the issue, that TTFB is how long the server is taking to process your request, meaning that it has something to do with your application server having an issue. Have you activated the "minimal download content strategy"? If so deactivate it, it will load the webpages two times (On my experience, to check for changes duplicating the TTFB before downloading the content). 8 secs is not awesome (The rest is in the ms range right?) but is not 3 minutes like you are stating. – Yugo Jul 11 '16 at 15:19
  • In my opinion that can't be the source of the problem. The farm is slow for two weeks. Before that it was "lightning" fast. – Patrick Jul 11 '16 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.