Port or Move DataView WebPart from one site or server to another site or server:

Dataview webparts can be developed in development environment and can be ported to a different environment as shown below:


• Edit the WebPart Page > WebPart > Export the Dataview Webpart and save it.


• Import the Data View Webpart on the intended site > webpart page

• The WebPart should display error not the page, i.e. page should render correctly.

• Open the WebPart page using SharePoint designer, go to DataFormWebPart and change the following as shown below:
  or you con modify the .webpart file itself.

Plan SharePoint Application for Optimum Performance

 Ten points to consider for performance out of many other.

1. Distribute user data across multiple content databases
2. Limit navigation depth
3. Defragment database indexes
4. Minimize page size, for internet facing sites or Lazy Loading
5. Isolate search indexing
6. Configure SQL parameters i.e. connection pool, indexes, so on
7. Separate user and database traffic i.e. seprate networks
8. Configure IIS compression
9. Take advantage of caching
10. Manage page customizations

Refrences:

• Blog
• CIO Magazine

SharePoint Farm Communication - can be performance bottleneck

This blog helps to ensure that the SharePoint Farm communication is not becoming the performance bottleneck for the application deployed onto the SharePoint farm.

SharePoint Application Communications:


Inter Server Communication

• Within the SP Server Farm.

Intra Server Communication

• Between SP WFE Server and External Server (system).

Client Server communication

• Client Browser/Machine and SP WFE Server

Database Load

• SP SQL Server database



Tools used to analyze the communications mentioned above:

Inter Server Communication

• WireShark Installed on WFE Server

Intra Server Communication

• WireShark Installed on WFE Server

Client Server communication

• Http Watch on Client Machine

Database Load

• SQL Profiler on the SP SQL DB




Identify the IP of all the Involved Servers

1) SP SQL Database server

2) WFE Server(s)

3) DNS

4) ISA

5) Application Servers

6) Client Machine

7) External Business application servers




Execution Pre requisites:

If applicable perform the following

1) Remove load balancing

2) Blank homepage for client machine browser

3) No one else other then the person performing network analysis i.e. any other user (application user or admin user is accessing the SP farm or the application by one or the other mean)

4) Make sure the external servers are up and running.



Execution Steps:

1) In the SP Farm restart the following services on all servers as applicable

• IIS

• SQL Server Service

2) Clean the client machine browser cache, close and open again.

3) Run the Wireshark on the WFE

4) Run browser with httpwatch on Client machine

5) Browse to site, stop and save the results of wireshark and httpwatch.





Analyze the WireShark and HttpWatch Results, following can be leveraged:

Protocols used between SP servers

o For database it’s TDS.

o Used by search and query services is SMB

o Obviously, also the http protocol.

Ports used in communication

o SQL Server 1433

o AD Authentication on TCP:445 or TCP:88 (Kerberos)

o LDAP:389 and LDAPS:636

o DNS on TCP:53

o SMTP on TCP:25

o Shared Service Provider web service calls on 56737 & 56738 (SSL).

In Wireshark

o Use “follow by tcp stream” to look for time duration, hiccups

o Filter by “tds.size>0”, “ip.dst eq 10.98.88.234”, …

o Look into packet details like sequence, offset and so on

 
Using the above steps you can disect the communication between the servers and pin point the cause or track down the server, which is culprit for the poor performance of the application deployed on to the SharePoint farm.

Once the cause is identified, we can perform the following

Deep Dive Analysis using one of the below method as applicable


• Code profiling

• Third party tools like idera to identify the component quickly

• System tools like perfmon

• Track Un Ghosted Pages: ghost hunter tool

• SQL Profiler

* Look at other performance related blog at my site

References:

• Wireshark
• Httpwatch

SharePoint Page performance based on component performance

When navigating to a Sharepoint site home page or any other page and it seems to take ages before the page loads, there can be multiple reasons but the one's we are focusing here is at the component level.

A SharePoint page can consist of many parts like

• htlm controls
• web controls 
• webparts

In some scenario, few pages on the site are slower compared to others or all the pages are slow regardless. To find that the bottleneck is one of the component listed above, we can go ahead and use the trial version of Idera tool. We can also use the code profiling but this tool can help us to do the profiling of the component which are slow instead of profiling all components.

It displays the result as follows:

As you can see in the above screenshot, the components are slow but not one particular most of them are slow. Which means, instead of focusing on one component, we need to take a look at the overall communication between the servers in the farm.

On the otherhand, if we would have found slowness with one particular component or few components then we can go ahead with profiling, code review, memory leak and so on.

If we are looking at the overall slowness or other issue please check my others performance related posts.