Interesting things about ECM

2009/10/06

SharePoint Scaling Limits

Filed under: General, Performance, Scalability, Sharepoint — Tags: , — Anthony Fast @ 6:14 am

Source: http://old.markharrison.co.uk/blog/2004/09/sharepoint-scaling-limits.htm

I frequently get asked for SharePoint scaling limits so I though I would blog an entry I can refer people to.

First an extract from the Capacity Planning section of the Windows SharePoint Services Administration guide which answers general WSS limits questions:

None of these are hard limits enforced by the system. They are guidelines for designing a server that has good overall performance.

  • Site collections (Database scope) 50,000 … Total throughput degrades as the number of site collections increases.
  • Web sites (Web site scope) 2,000 … The interface for enumerating subsites of a given Web site does not perform well much
    beyond 2,000 subsites.
  • Web sites (Site collection) 250,000 – You can create a very large total number of Web sites by nesting the subsites. For example, 100
    sites each with 1000 subsites is 100,100 Web sites.
  • Documents (Folder scope) 2,000 … The interfaces for enumerating documents in a folder do not perform well beyond a thousand entries.
  • Documents (Library scope) 2 million … You can create very large document libraries by nesting folders.
  • Security principals (Web site scope) 2,000 … The size of the access control list is limited to a few thousand security principals, in other words users and groups in the Web site.
  • Users ( Web site scope) 2 million … You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users.
  • Items (List scope) 2,000 … The interface for enumerating list items does not perform well beyond a few thousand items.
  • Web Parts (Page scope) 100 … Pages with more than 100 Web Parts are slow to render.
  • Web Part personalization (Page scope) 10,000 … Pages with more than a few thousand user personalizations are slow to render.
  • Lists (Web site scope) 2,000 … The interface for enumerating lists and libraries in a Web site does not perform well beyond a few thousand entries.
  • Document size (File scope) 50 MB … The file save performance degrades as the file size grows. The default maximum is 50 MB. This maximum is enforced by the system, but you can change it to any value up to 2 GB (2047 MB) if you have applied Windows SharePoint Services Service Pack 1.

For SharePoint Portal Server, here’s an extract from the Capacity Planning whitepaper:

It is important to understand the ramifications of the different features and functions of the SharePoint Portal Server solutions to size the system so that the performance of the system is good.

The following table lists some of the SharePoint Portal Server objects and describes their recommended use. “Typical” indicates comfortable and well tested; “maximum” indicates that the system can support that number, but not without some performance ramifications or
special configurations.

An asterisk (*) indicates a hard limit; no asterisk indicates a tested or supported limit.

  • Portal sites (full) – typically 2 … maximum 15 *
  • Portal sites (child) – typically 10 … maximum 100 *
  • Areas – typically 1,000 … maximum 10,000
  • Best Bets – typically 1,000 … maximum 25,000
  • Area depth – typically 5 … maximum 20 *
  • User profiles – typically 50,000 … maximum 1,000,000
  • Audiences – typically 500 … maximum 10,000
  • Audience memberships – typically 500,000 … maximum 5,000,000
  • SSO credentials – typically 100,00 … maximum 100,000
  • Search indexes – typically 3 … maximum 32
  • Content sources -typically 25 … maximum 250
  • Search scopes – typically 25 … maximum 250 *
  • Indexed documents per content index – typically 100,000 … maximum 5,000,000
  • Indexed documents – typically 2,500,000 … maximum 20,000,000
  • Thesaurus entries – typically 1,000 … maximum 10,000
  • Alerts – typically 50,000 … maximum 1,000,000
  • Team sites – typically 10,000 … maximum 250,000
  • Personal sites – typically 10,000 … maximum 250,000
  • Advertisements

    Understanding the differences between Alfresco’s repository implementations

    Filed under: Alfresco, General, Performance, Scalability, WCM — Tags: , — Anthony Fast @ 6:14 am

    Source: http://ecmarchitect.com/archives/2009/08/31/1038

    People new to Alfresco are often unaware of the existence of two different repository implementations within the product. One, which I’ll call the “DM Store”, is the classic store, the one that’s been used by Alfresco since the beginning. The other, the “WCM Store” or, as it is often referred to in API-speak, the “AVM Store”, was born with the addition of the Alfresco WCM product offering. Whether you are doing document management or web content management, you use the same Explorer client, but under the covers, your content lives in two very different types of repositories.

    The Alfresco story on why a second repository implementation was created is that the Engineers writing WCM didn’t believe the DM store was capable of providing the kind of support for versioning, branching, and layering functionality they needed (hence, the AVM acronym, which stands for Advanced Versioning Manager) so they created an entirely new repository implementation to support WCM.

    Why does this matter, apart from being a possible topic of conversation at your next get-together (”Healthcare is easy to fix. Do you think Alfresco will ever unify their two repository implementations?”)? It matters because the “two sides” of Alfresco are not equivalent in terms of functionality and depending on what you need to do, you may find yourself performing unnatural acts to work around the disparity.

    Many projects will be completely unaffected by the differences between Alfresco DM and Alfresco WCM. But it is important to know what these differences are when you first begin to plan your solution to avoid uncomfortable conversations between you and your customer when you realize you’ve made a bad assumption.

    I’ll assume you know the high-level capabilities of both Alfresco DM and Alfresco WCM. Obviously there are some things one product can do that the other can’t that are by design (sandboxes and virtualization in WCM, for example). What’s more important to understand are the subtle (and sometimes not-so subtle) differences between the two. Here’s the list and a table that summarizes, if you are into the whole brevity thing:

    Content Modeling. Alfresco DM uses a proprietary XML-based description of the content model while Alfresco WCM uses XML Schema. On the surface this isn’t a big deal, but it does mean if your repository contains a mix of DM- and WCM-stored data, you won’t have a single model that defines it all and you could possibly have duplication between the two.

    Custom Content Types. In Alfresco DM, when you create content, you tell Alfresco what its content type is. If you’ve extended the out-of-the-box model, you can have any number of business-specific content types with your own custom metadata. In Alfresco WCM, custom content types are not supported. In WCM, your content type is your web form. Interestingly, although the “Type” dropdown is shown in the “Create Web Content” dialog, and it will contain custom content types you’ve defined using the Alfresco DM model, your selection will not be honored. All AVM content is created as an instance of the “avmplaincontent” content type no matter what you select. However, although you must do it through an API call, you can apply custom aspects to AVM content.

    User Interface Configuration. Alfresco DM uses a proprietary XML-based configuration file to define the “property sheets” that display metadata in the Alfresco Explorer client for a given content type or aspect. Alfresco WCM uses the embedded Chiba XForms engine to inspect the XML Schema (XSD) and automatically create a web form that will produce data that conforms to the XSD. XSD annotations can be used to influence the presentation of the form fields. One outcome of this is that it is much easier to localize things like property labels in Alfresco DM than it is in Alfresco WCM.

    User Interface Extension. If you need to change how the Alfresco Explorer client behaves, there are some things you can do through XML, but advanced customizations will require JavaServer Faces (JSF) development. Alfresco DM and WCM both use the same Explorer client so this applies to both (See “Alfresco User Interface: What are my options?”). However, if you need to change how the web form engine works, you may need to write new Chiba XForms widgets. For instance, Optaros developed a web form used to describe points and regions on Google Maps. That kind of thing requires you to understand how to extend Chiba.

    Structured (XML) data entry. Data entered in an Alfresco WCM web form is saved as XML that conforms to the XSD you’ve defined. There is no similar facility for capturing data as XML available within Alfresco DM. At one point the Community code line had “ECM Forms” which was essentially WCM web forms for the DM side of the house, but that’s disappeared in the latest Community release. On the DM side, when you edit metadata you are editing object properties whose values get stored in the database, not as XML.

    Transformations. You can use either Freemarker or XSLT to transform Alfresco web form XML into other formats. That transformation is defined as part of the web form configuration which you do within the Explorer client. In Alfresco DM, transformations are more about binary file transformations (DOC to PDF or GIF to PNG, for example). If you want to do Freemarker or XSLT transformations on XML content stored in Alfresco DM, you’ll need to write that yourself (an Action would do the trick). If you want to do DM-style transformations on binary files in Alfresco WCM, that’s not out-of-the-box. You’ll have to do that using the API.

    Rule actions. Alfresco DM allows you to configure rules on folders to trigger actions (out-of-the-box or custom) to operate against newly-added, updated, or deleted documents. Alfresco WCM does not support rule actions at all.

    Auditing. Alfresco DM has a granular auditing sub-system. You can configure it to audit just about anything you want. Anything except WCM. You can audit web project creation, but not changes to individual web assets within a web project. At least not out-of-the-box.

    Object-level permissions. In Alfresco DM you can assign users and groups to roles at the folder and file level. In Alfresco WCM, the UI will only let you go as low as the web project level. The API supports more granular security but you have to implement that yourself with custom code.

    Search. Everything in Alfresco DM is full-text indexed and searchable. In Alfresco WCM, only the Staging Sandbox of each web project is indexed. You can do a search from your user sandbox but you’re really searching the Staging Sandbox. If you have any content you’ve created in your user sandbox that you have not yet committed to Staging, web project search won’t find it. Another limitation is that you cannot search across web projects. That search box that’s visible in the far upper right-hand corner of the Alfresco Explorer client is the Alfresco DM search–it won’t find anything in any of your web projects.

    Advanced Workflow. Alfresco DM and Alfresco WCM use the same JBoss jBPM workflow engine so there’s no functional difference between what you can do with workflow on either side. The only catch is that in Alfresco DM, all deployed workflows show up in the “Start Advanced Workflow” dialog whereas in WCM, you have to tell Alfresco which deployed workflows are okay to use for WCM. That’s covered in the Alfresco Developer Guide and on the wiki.

    File protocols. CIFS and FTP are the only two file protocols supported by both Alfresco DM and Alfresco WCM. Similar protocols supported by Alfresco DM such as WebDAV, inbound SMTP, and IMAP, are not supported by Alfresco WCM.

    Deployment. Some people use Alfresco DM to manage content that is published to the web because they don’t need the additional features WCM offers, or they have some other reason to export content to another server. Unfortunately, Alfresco DM does not yet offer a deployment component like the one in Alfresco WCM. If you want to export content from Alfresco DM to some other destination in a systematic way, you’ll have to roll your own solution.

    As John and Paul said, “It’s getting better”

    Some of these differences will become less drastic in coming releases. For example, Alfresco is implementing a new form service that will be used to define the content model and user interface across the entire product line, so that helps. The WCM deployment functionality is also being refactored and will ultimately work for both DM and WCM. And at every community event Alfresco talks about “repository unification” as a goal for the future, although the timeline is lightyears away in terms of software releases.

    As I said, depending on what you’re doing these differences may not affect you at all. Just make sure you don’t assume that a given feature is available everywhere, and make sure you’ve made a conscious decision about what content to put in which repository (DM or WCM) based on your requirements.

    Blog at WordPress.com.