Tuesday, February 1, 2011

Managing Sandboxed Solutions

Managing Sandboxed Solutions

Sandboxed full-trust solutions are new to SharePoint 2010 and were created to provide new levels of flexibility and control when deploying SharePoint Server 2010 artifacts. Instead of deploying items farmwide, sandboxed solutions are contained within a single site collection. Instead of being stored in the solution store, sandboxed solutions are stored in the site collection gallery like Web parts and list templates.
Although allowing information workers to deploy code might seem risky at first glance, sandboxed solutions actually provide a security enhancement compared to full trust solutions. Sandboxed solutions are run using a restrictive set of code access security policies and are limited to a specific subset of the SharePoint Server 2010 object model. In addition to running with limited trust, sandboxed solutions are monitored to ensure that they do not affect server performance by consuming too many system resources. Furthermore, because sandboxed solutions are limited to operation within a single site collection, problems are limited to only that site collection.

Sandboxed solutions have the same basic structure as full-trust solutions. They are cabinet files with the .wsp suffix instead of .cab. They contain an XML file named Manifest.xml that describes the contents of the solution and how to deploy the. As with full-trust solutions, you can inspect the contents of a sandboxed solution by changing the file extension to .cab.

For sandboxed solutions to run properly, the Microsoft SharPoint Foundation Sandboxed Code Service must be started. The service does not have to be started on every server, only on the servers that will run sandboxed solutions.
Sandboxed solutions are uploaded, activated, deactivated, and deleted. Upon being uploaded to the gallery, a sandboxed solution does not automatically do anything, it is simply available to be activated.

Sandboxed Solution Monitoring
One of the biggest advantages to sandboxed solutions is the ability to monitor them and terminate execution if they consume excessive system resources. Sandboxed solutions have been moved entirely out of the standard Internet Information Services (IIS) worker processes and are instead run in a separate proces named SPUCWorkerProcess. Usage quotas can be set for each site collection, and sandboxed solutions that exceed the quota for a site collection will not be allowed to run.

The Sandboxed Solutions Resource Quota value specifies a maximum resource utilization for sandboxed solutions for the selected site collection. The value is specified in resource points. The resource components are themselves based on a set of 14 metrics that measure specific conditions
When the quota is exceeded by one or more solutions, no sandboxed solutions can run in that site collection for the remainder of the day. If a single sandboxed solution consumes more than 85 procent of processor time or if it encounters more than three unhandled exceptions, it is locked

Sandboxed Solution Load Balancing
By default, sandboxed solutions run only on servers that have the Microsoft SharePoint Foundation Sandboxed Code Service running. This allows sandboxed solution execution to be offloaded from individual Web front-end servers and isolated on one or more servers. To change the sandboxed solution load-balancing scheme, select either All Sandboxed Code Runs On The Same Machine As The Request or Requests To Run Sandboxed Code Are Routed By Solution Affinity.

To prevent a truly pernicious sandboxed solution from executing, you can implement a list of blocked solutions.

Tuesday, January 11, 2011

Tools to optimize the performance for SharePoint 2010 Server

Large List throttling is good for limiting the load time on lists with large numbers of items
HTTP Request throttling can keep the server from losing data during high utilization
Developer dashboard can be used to monitor performance on page loads

By default the Developer Dashboard is turned off. When the Dashboard is on, every page will render the dashboard, all the time. In on-demand mode, the dashboard can be accessed as needed by web administrators.

When the Developer Dashboard is turned on, it will only be visible to users with Full Control.
This means that for example on a My Site when the Developer Dashboard is turned on, the user who has full control on his/her my site will be able to see the dashboard.

What information is visible on the dashboard:
- times to render various components on the page
- pages checkout level
- database query information
- web part processing time
- any critical events or alerts

Good for diagnosing problem web parts on a page or long list load time

How to enable the Developer Dashboard?
stsadm -o setproperty -pn developer-dashboard -pv OnDemand (Off or On)

Its a Farm wide setting!

When you're able to see the dashboard you can also see a correlation ID which you can use to trace the ULS logs.