For some it’s hard to understand why SharePoint became that popular – and quite honestly – a lot of projects I’ve seen being implemented on SharePoint make me wonder why they chose SharePoint in the first place. But – there are a lot of great things about that platform that make it very interesting for enterprises to use it for various aspects.
A big problem I see is that SharePoint Administrators, Operators and Developers of customized SharePoint solutions neglect the performance aspect of SharePoint and with that, they jeopardize SharePoint adoption in their organization. Why? Because SharePoint provides so much out-of-the-box, it’s easy to use and configure and we just add more hardware to make it faster instead of analyzing why it is not performing as expected.
In this blog I show you how in 15 Minutes you can do a basic sanity check on your SharePoint installation or your custom SharePoint developed solution. If you don’t have time to read this, I also recorded all these steps and put it on YouTube: Watch: SharePoint Performance Sanity Check in 15 Minutes
What Are the Top SharePoint Performance Problems?
Several years back I blogged about the Top SharePoint Performance Problems. Up to this date these blogs are still among the Top 3 blog topics on our performance blog and I still receive feedback that these problems are still the ones seen out there. This is the reason why I wanted to write this blog on how you as a Developer, Tester, Administrator or Operator of SharePoint can do a quick performance sanity check on your SharePoint installation using the Dynatrace Free Trial. Using the SharePoint FastPack I built for this blog allows you to get to the following dashboards within 15 Minutes:
The following is a custom built dashboard that is included in the FastPack. It focuses on the top SharePoint URLs, WebParts, Overall Response Time and Memory Usage:
These and other dashboards allow me to analyze any performance hotspots, configuration or deployment issues in a SharePoint installation. As one responsible for SharePoint you want to know
- Why certain Pages, Lists or Views in SharePoint are slow
- Which WebParts have implementation issues such as inefficient Database access or bad coding
- Whether you have configuration problems that lead to bad or slow behavior
- Which Pages, Lists or Views are actually used or are not used
- Whether your current Server Resources (CPU, Memory, Disk, Network) can handle the expected load
If you don’t have a SharePoint installation on-hand or you can’t install Dynatrace to test this out don’t worry. I’ve exported data from my SharePoint test environment and uploaded it to our Share Your PurePath page. Follow my video tutorial on that page and explore what data Dynatrace can show you without having to install Dynatrace on your SharePoint servers.
15 Minute Sanity Check in 5 Easy Steps
I based this blog on my local SharePoint test environment. I have SharePoint 2010 installed on a virtualized Win2008R2 (machine name: lnz-dt-ws08r2-lab05v). I decided to install Dynatrace (Server, Collector & Client) on a dedicated Windows 7 (machine name: lnz123737n02). It is perfectly fine to install Dynatrace on the SharePoint server but I decided to use a separate machine which is a Best Practice Dynatrace deployment scenario. The only thing I will need to install on the SharePoint server is the so called Dynatrace Agent which will monitor the activity in SharePoint reporting the data back to Dynatrace on my Win 7 machine:
Now let me guide you through the steps I took in my environment. This should not take longer than 15 minutes (excluding the download time of Dynatrace):
Step #1: Download and Install Dynatrace Free Trial
Dynatrace is available as a 30 Day Free Trial with the option to get a “Lifetime” license through our Share Your PurePath program. After I registered I received a confirmation email to activate my account. I specified my new Dynatrace Community password and end up on My Dynatrace Trial page where Step 1 gives me the link to download the installers for Windows (or Linux in case I want to run my Dynatrace Server on Linux). I choose to download the 64bit installer for both Windows. It is a 500MB .msi file and includes all Dynatrace components.
Tip: We had users Anti-Virus Software that didn’t allow downloading .msi files. Make sure this is not blocking your download.
Once downloaded I launched the installer on my Win 7 machine, simply clicking through the Wizard until all is installed. At the end of the Installation the Dynatrace Client will launch automatically (or you can launch it through the Start Menu). Upon first start I am prompted for a License. I can either choose to use the file that I received via email or simply use my username and password to activate the license online.
Tip: If you haven’t received a license or if you have problems simply send me an email.
Step #2: Download and Install SharePoint FastPack
Now I would normally walk through the Wizards in Dynatrace to configure my system or follow the steps on My Dynatrace Trial page on how to configure and install agents. But – I’ve create a special Starter Package for SharePoint which eliminates these steps. We call these Packages FastPack’s as they give you a Quick Start on certain environments including pre-configured dashboards and reports. So – I download the latest version of the SharePoint FastPack and save the .dtp file on my local machine. Get the latest version of the FastPack from the SharePoint FastPack Community Page.
To install, I either double click on the .dtp file in my Windows Explorer or choose Tools -> Manage Plugins from the Menu in your Dynatrace Client. Then I click on “Install Plugin” and select that file. There is a warning message asking me if I am sure to install: I AM SURE! J
Once the file is imported I get a success notification. Back in the Dynatrace Client I can now pick “SharePoint” from the top left Drop Down menu and get the following screen:
The FastPack also includes the SharePoint Sample Session file from my test environment. That’s why you (in case you try to follow these steps) can actually look at the same data I recorded while creating this blog in your local Dynatrace Client:
Step #3: Configure your IIS and SharePoint AppPool
But now back to setting this up for my SharePoint installation. The FastPack comes with a pre-configured Dynatrace System Profile called SharePoint. It is expecting two different types of Agents to connect and send data: WebServer (IIS) and SharePoint (the actual SharePoint AppPool). In order to avoid any conflicts with other System Profiles I expect the Agent Names to be WebServer_SharePoint and SharePoint_SharePoint.
So – all I need to do now is to install the Dynatrace Agent on my SharePoint server and configure these agents to monitor the traffic coming on in IIS and the traffic going all the way into SharePoint’s AppPool
#3a: Download the Dynatrace Agent for my SharePoint Server
As I have SharePoint running on a different machine I download the Dynatrace Agents for Windows msi file and run the installer on that SharePoint Server. I click through the Installation Wizard and go with all defaults allowing it to automatically activate the .NET and Web Server Agent.
Tip: Depending on your windows version you may want to restart your Windows Server so that the registry keys and environment variables Dynatrace configures are really picked up by IIS and SharePoint which we will configure in the next steps
#3b: Configuration of Dynatrace Web Server Agent for IIS
Dynatrace can monitor every single web request handled by IIS for all or a particular Site it is hosting. In my case I want it to monitor my SharePoint site. In order for that I need to configure the Dynatrace Web Server Agent and Configure IIS to load the Dynatrace Web Server Module:
Configure Dynatrace Web Server Agent:
- I edit the file dtwsagent.ini which I find in my Program Files\dynaTrace\agent\conf directory
- I need to change the Name property from dtwsagent to WebServer_SharePoint
- I also need to change the Server property to lnz123737n02 (name of my Dynatrace server)
- I save the file
- Now I open the Windows Services and restart the dynaTrace Web Server Agent 6.0.1 Service
Configure Dynatrace Web Server Module:
- I open IIS Manager
- I navigate to my SharePoint site and click on Modules
- I click on Configure Native Modules and select both dynaTrace Web Server Agent Modules (32 and 64). That’s OK as IIS is smart enough to know which version to load
- If I would have more than I site I can repeat this for other SharePoint Sites, e.g: the Central Administration Portal
#3c: Configuration of Dynatrace .NET Agent for SharePoint AppPool
Dynatrace can monitor ANY .NET Application on my system. In order to tell Dynatrace which particular .NET Application to monitor I use the dynaTrace Agent Configuration Tool for .NET and pick a process that I am interested in. To make it easier I ensure that SharePoint is currently running. I open the browser and browse to the site.
When I launch the Agent Configuration Tool the first time it shows me an empty list as nothing is configured by default. I click on the ‘+’ button which gives me a list of currently running .NET Processes. If SharePoint is currently running I can see several w3wp.exe processes which are the ASP.NET Worker Processes. In the next column I see the name of the application pools. I pick the one that has SharePoint in its name. The next dialog pops up allowing me to specify Agent Name and Dynatrace Server endpoint information:
Once you click Finish you are back in the tool seeing that we have one agent configured.
3d: Restart IIS and Browse to SharePoint
The last step I have to do is to either restart IIS (iisreset) or restart the Application Pool of SharePoint. After that I also open the browser and browse to SharePoint so that IIS is actually initializing the AppPool and with that loading the .NET Runtime and also the Dynatrace Web Server and .NET Agent
We can verify if these Agents connect successfully by looking at the Agent Status:
If you don’t see your agents make sure you followed all the configuration steps. Make sure that your SharePoint server is not blocked by a firewall as it needs to connect to your Dynatrace machine on port 9998. Also make sure you restarted IIS and after that accessed SharePoint to make sure it’s up and running. If you still have problems let me know.
Step #4: Put some load on the system
If my SharePoint server would be a live production system or a test system with some load on it I would be good and could just start watching the recorded data in Dynatrace. In my case I am the only using this SharePoint server so I need to create some traffic in order for Dynatrace to pick up the activity. I simply click through different pages – Hit F5 in my browser multiple times to simulate some load. If you have the chance and the tools available I suggest you execute a small load test or ask your colleagues to open their local browsers and help you generate some traffic. That’s going to give you much more data to play with.
Step #5: Identify Performance Hotspots
When I now go back to my Dynatrace Client I see the Monitoring Dashboard showing data from my environment. Depending on how much load I put on the system there is more or less to see of course J There are multiple options I have on that dashboard. The most interesting ones are highlighted in the following screenshot:
If you want to learn more about general basic diagnostics steps, e.g: finding out which database statements are slow or which code spends too much time on CPU check out my YouTube Video on Basic Diagnostics Steps with Dynatrace.