Microsoft Office Tutorials and References
In Depth Information
often than not. That’s why you need to monitor how your SharePoint server handles the stress of
use, just in case. If you can afford it, consider calculating your OPS requirements and then
doubling them to prepare for the inevitable, large increase in use.
Additional Performance Considerations
You’ll want to keep an eye on these items that will increase your processor’s load:
Alerts Users can set alerts on changes in a list or library. Alerts are scheduled and,
therefore, keep the SharePoint Timer services busy. Limit the number of alerts your users can have
running at any given time. It will save your processor. Alerts can be configured with a user
limit or disabled altogether.
Indexing The server that will be indexing site collection content will have to support the
increased load on the processor. If you can, try not to index every five minutes or less. Instead,
it’s better to index every hour or at certain times of the day. This can be difficult if you expect
SharePoint to index and search new items almost instantaneously; just keep it in mind if you are
trying to squeeze as many operations per second as you can from your server. Indexing can be
RAM-intensive. If your server is taking a long time to index documents and indexing is peaking
your RAM usage, consider increasing the RAM on the server doing indexing.
Usage and Health logging SharePoint can analyze site usage and deliver detailed reports.
However, analyzing the usage logs takes a considerable amount of processor power. Try to
schedule the analysis to occur during a long downtime, usually sometime around 3 a.m.
Web Parts Your developers may go crazy with the power of web parts. Be careful; some
web parts (depending on what they do and how they were coded) can be resource hogs. Stay
well below 50 web parts per page—and that includes the hidden ones. Home pages, where
web parts are usually found, can be overwhelmingly busy.
Web Applications Although web applications may not, by themselves, increase processor
load, they do take up about 50 MB or more apiece in RAM on the SharePoint server (espe-
cially if they are using different application pool accounts). This is one of the reasons that you
might want to consider consolidating site collections into as few web applications as possible.
Features and Solutions Custom features and solutions can be added to SharePoint and
scoped at the farm, web application, or site collection level. Be sure to test those added
components to know how many resources they use when active. Realize that although now there can
be sandboxed solutions, or solutions that are deeply throttled in terms of the resources they’re
allowed to use, and scoped to be added and activated at the site collection level, no matter how
frugal they are, if you have many solutions or features they can impact the server’s CPU and
RAM over time.
Storage Planning
When you’re considering performance issues, don’t forget to plan for adequate storage. If you
plan to have SharePoint and the SQL Server 2008 Express database on the same server, you’ll
need extra RAM because SQL uses quite a bit. But more specifically, it will require much more
storage space than SharePoint alone. Even if your SharePoint databases—particularly the
Search JabSto ::

Custom Search