How to Increase Performance of Sharepoint in all levels.

Tune your Sharepoint with following tips.Here are the tips given by me to our project Artcore.
Today i m going to blog how to increase the performance of our sharepoint portal in all the levels.
Performance of an application using MOSS framework can be increased by enhancing in either one or in all of the following areas.
1.0 Infrastructure.
2.0 IIS.
3.0 SharePoint portal.
4.0 Application.
5.0 Code Level

1.0 Infrastructure
SharePoint is an application that works best when it gets lots of memory and CPU resources. SharePoint’s Web role uses stateless connections. Using this as advantage, if we install the Web role on several servers, it is possible to divide the client load between them. However, for this we need to consider and solve two challenges first. One is to make sure all web servers have access to the same information which is done by using a common back-end database for all of them. The second thing to solve is that all of these web servers must look like one single SharePoint server which is done by using (NLB). SharePoint supports up to eight servers running the web service role.
1.1 Index server
Different activities in SharePoint require different extent of resources; for example, displaying a project Site normally generates a very light load on the server, whereas indexing the database generates much higher load.

The Index service including the crawling activity is very resource intensive regarding CPU and disk access. By separating this service from the Web, many more users will be supported in the SharePoint environment. The indexing activity can be split between up to four different SharePoint servers.
Note: Only one Index server can crawl on a given content source. If one index server goes down, no other server will take over the indexing crawling that server is configured to do.

With below topology we can double the performance, availability….,

Picture to be placed here.

1.2 Calculating the Number of Operations per Second (OPS) required
For computation of the load or the OPS, on the SharePoint server, the following formula is used

(http://blogs.technet.com/wbaer/archive/2007/07/06/requests-per-second-required-for-sharepoint-products-and-technologies.aspx)


A*B*C*D /360,000*E= OPS
Where,
❑ A = The number of users.
❑ B = The percentage of active users on a typical day.
❑ C = The number of operations per active user per day.(1-10)
❑ D = The peak factor.(1-10)
❑ E = The number of working hours per day.

For ArtCore

A= ~ 1000
B= ~ 100
C=~10
D= ~10
E= 12

1000*100*10*10/360,000*12=10000000/4320000 = 2.31 OPS.

By Redesign we can manage up to 20,000-40,000 of users.

1.3 Requests per second
The general rule is to plan for 1 Rps. While a small server farm serves about 60 RPS for 1000 users, a medium farm with 2 WFE servers can serve about 120 Rps.

1.4 Disk Space Needed
When planning for the required disk space, there is no need to worry about the SPS binary files, because they are small compared to other files. More important are the index and database files. Regardless of the database type, you still need to follow this important rule:

You must always have at least 50 percent free space on your database disk!
The reason for this is that some database troubleshooting utilities need to make a copy of the database to perform their tasks. If you don’t have the required space, you may get into a situation where you cannot fix a problem.



2.0 IIS
2.1

When creating a Web Application (and associated site collection) that the default is that a unique IIS application pool be used for each. This can have several benefits – should some unexpected error in a site cause a problem it will be localized to that site collection, additionally the worker process will be caching content related to those specific sites. Worker process sizes between 250-300MB on X86 WFE servers, and between 400-500MB on X64 WFE servers. There are also other application pools and related IIS processes to support Central Administration, SSP, and so on, on the various WFE servers. The best-practice approach will be to consider which Web Applications should share an application pool, and which should be unique. Using multiple application pools can be beneficial, but it is easy to over-do by always taking the default settings (use new pool). Each related process has to load an instance of the .NET runtime in memory, so un-needed (excessive) application pools can waste memory.

2.2
IIS Compression
HTTP Compression is a wonderful technology that accomplishes a lot of different things. It allows faster page serving to clients and lower server costs due to lowered bandwidth (these two being enough for me to implement).

HTTP Compression is when a Web server receives a request for a file and instead of just serving the file to the client, it checks to see if the client browser (or application) is "Compression Enabled". If so, the Web server does a check on what type of file is being requested (this is determined by the file’s extension). If the file is marked as a static file, such as an HTML file, IIS will check the Compression Cache Temporary Directory.

If a compressed version isn’t found, IIS will send an uncompressed version of the file to the client and a compressed version is placed in the temporary directory (IIS will only serve to the client from the temp directory). If the compressed version is found, IIS will send the file directly to the requesting client. If the requested file is a dynamic file, such as an ASP.NET Web form, then the response is dynamically compressed and sent to the requesting client (no temp directory access is ever done).

By running the below scripts we can achieve compression
cscript.exe adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "dll" "exe" "aspx" "asmx" "ashx"
cscript.exe adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "dll" "exe" "aspx" "asmx"
cscript.exe adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"
cscript.exe adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true)
3. 0 SharePoint level
3.1 Caching
SharePoint provides two types of caching.

3.1.1 Page output caching
3.1.2 Disk caching

Disk-based cache scheme can be enabled on a per-site basis, and should be set consistently on each WFE server. In a typical site there are likely several references to image files (BMP, JPG, and so on) or to CSS style sheets or JS script files. These can be cached to avoid repeated database access for what are essentially static objects, and thus improve page response times. The cache is disabled by default, and is enabled by editing a line in the site WEB.CONFIG file found in the IIS Inetpub folder structure related to the site on the server’s system disk. Edit the file and search for the second instance of “BLOB” to get to the right line, which looks like:

<(BlobCache location="E:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="100" max-age="86400" enabled="false" )/>

Currently in production it is set to “false”.
The maxSize parameter is the maximum size of the disk cache in GB.
4.0 Application level
Our Project’s Key strength is InfoPath forms.
InfoPath Forms Services uses session state to store the large amount of transient data generated while filling out a form. As a result, front-end Web servers can remain stateless between round trips, and each post back is not burdened with carrying large amounts of session state information over narrow bandwidth pipes.

So if you are using infopath forms use formview state rather than session state.

5.0 Code Level
Many times we will delete or update list items in the lists by using Object oreiented code if these operations or doing on lists having bulk items then use
"ProcessBatchData" we can increase performance very much.

http://msdn.microsoft.com/en-us/library/cc404818.aspx

Advantages:
1) Performance
2) High availability(WFE & DB)
3) High Throughput
4) Scalability
5) No downtime