INTRODUCTION
Hi everyone, in this opportunity I would like to share with you some of the tips that can help us tuning our SharePoint Farm performance. This is a series. Please also note that all of the articles mentioned in this series are purely based on my experience and some readings that I’ve done myself only. Therefore, please share your thoughts and opinions.
HARDWARE REQUIREMENTS
I have to admit that SharePoint consumes a lot of server resources. Therefore, the very first step to tune SP farm performance is by ensuring that we’re using the appropriate hardware. There are basics that we can follow regarding hardware requirements:
64-bit compliant
Ensure that the hardware we’ll be using are 64-bit compliant. In fact from this moment on I will not be installing SharePoint on hardware that’s not 64-bit compliant. The reason is because 32-bit environment can only handle less than 4GB of RAM. Therefore, for scalability I will always use 64-bit compliant hardware.
Fast network cards
Since there may be huge traffic coming in/out the SharePoint servers, use gigabit NIC if possible.
Disk speed
SharePoint also does a lot of disk read/write through its content databases. Therefore, the faster your disk speed the better.
Plenty of RAM
I personally will always start with 4GB of RAM for the Sharepoint Server and 4GB of RAM for the database server. In fact for SP 2010, Microsoft suggests that you’ll need 8GB for the Sharepoint server itself.
SharePoint is very RAM intensive. You’ll expect at least 1.5GB of RAM usage on the database server itself. That’s given that the database server only contains SP databases. If you use a shared DB server (ie. shared with other custom apps) then you’ll probably need more RAM.
Minimum hardware requirements
Ensure that you adhere to Microsoft’s minimum hardware requirements for installing SharePoint. I’m sure Microsoft has tested this themselves.
For more information please visit http://technet.microsoft.com/en-au/library/cc850692(office.12).aspx.
SERVER TOPOLOGY
The minimum topology you’ll need will be 1 dedicated Sharepoint server and 1 dedicated database server. NEVER put database and Sharepoint on the same server!
The dedicated Sharepoint server can have all of Sharepoint features inside (eg. Central Admin, Indexing, Search, etc) and we can always scale this out into more servers when required. However, throughout my experience, the bottleneck is always on the database server. Therefore, you can imagine how slow it’s going to be if the DB, OS, Sharepoint are all on the same server.
CONCLUSION
So, when we’re about to deploy Sharepoint, ensure that we have kept this in mind. A lot of clients that I’ve been into think that “Oh…we can always expand later..let’s just use this spare VM for it”. But then in the end, upgrade can be painful and consuming so much time. Especially if SP has been running and the content database size has increased so much!
I’m actually writing this particular article during a client engagement which the client uses a 32-bit environment for their SP farm. They put DB and SP on the same server. The server itself can only have ~3.5GB of RAM max and the DB itself already consumes 1.7GB of RAM. This is a dedicated SP server by the way, therefore there’s no other application using the DB nor the server. There are now issues with downloading documents that are more than 700kb in size because the server just can’t hold them in the memory any more!
They’re in the process of upgrading their farm but of course it will take time to do. With all of the after hour outages, etc. It wouldn’t happen if they’ve been applying the basics I mentioned above. So yeah…plan this very first step well and we’ll save a lot of time and costs in the future.
