This is a collection of questions and answers about Microsoft® Content Management Server (MCMS) gathered from the MCMS newsgroup. This content is provided "AS IS" with no warranties, and confers no rights. If you have feedback about one of these topics or would like to add information, please post your comments to the MCMS newsgroup. Thank you, Stefan Goßner Escalation Engineer Steve Cawood Program Manager
I experience bad performance and high CPU after the worker process of my IIS website
MCMS works best if worker processes are not recycled.
The reason is that recycling of the worker process will cause an flush of the node cache as the node cache is part of the address space that gets recylcled. This means that further requests to the will cause a request flood to the SQL server. A single page request to the MCMS server can potentially cause thousands of requests to the backend SQL server - depending on the complexity of the templates and sites.
The recommendation for MCMS is to disable process recycling completly.
Process recycling has been implemented in Internet Information Server (IIS) to allow customers to deal with badly written applications that do not free resources (file handles, memory, ...) properly. MCMS actually does not require any recycling.
I'm looking for some best practice coding tipps about performance. Where can I find such tips?
Look in the following whitepaper. It contains a section named 'Specific Coding Practices' which covers this:
WoodgroveNet Sample Site for Microsoft Content Management Server 2002
Our site will be storing "gigabytes and gigabytes" of multimedia content. We need a content management tool, but it needs to be capable of storing all types of media (.WMA, .WAV, .MP3, .MP4, .MPEG etc. etc. ) and gigabytes and gigabytes of it.Can I be confident that MCMS is capable of handling such volume?
We are well set up for handling large numbers of small files. Even gigabytes and gigabytes of 1MB to 2MB short videos are fine (so long as your SQL server can handle it). But as soon as you talk about streaming video, you should look at some of our Digital Asset Management partners. If you put streaming video on a page, we are quite happy to manage everything around it. But uploading a 10GB video file from your desktop into a placeholder over HTTP is probably not the way you want to manage this. If you need streaming video, look at a joint solution.
I have heard that there is a limitation of 300 items in a posting or channel. Is this a hard limit?
There are two types of containers in the MCMS object model: channels and galleries. Channels contain pages and determine the site structure. Channels also allow you to control which users can view, edit, and approve those pages. Galleries contain templates or resources such as images. Galleries allow you to organize these objects in the database as you might files in a directory structure, and also allow you to control user access to these objects.
You can establish quite complex container hierarchies to capture both the site structure and the user rights required to control the site content. However, large container hierarchies carry their own performance cost. Therefore, it is best to limit the depth of container hierarchy.
Root Channel containers:Limit the number of containers under the root node. (For example, /Channels should not have more than 10 to 15 immediate children containers.) Items in a container: Limit the items in a container to less than 300. You can do this by distributing items over multiple containers, to ensure that the number of items in each container does not exceed 300.
Root Channel containers:Limit the number of containers under the root node. (For example, /Channels should not have more than 10 to 15 immediate children containers.)
Items in a container: Limit the items in a container to less than 300. You can do this by distributing items over multiple containers, to ensure that the number of items in each container does not exceed 300.
A value of 300 items in a container (200 for MCMS 2001), is a definite upper level of resources, not only from a performance stand-point but also for effective use of the container hierarchy.
The container performance is related to the fact that in order to get a container and the first 3 items say (sort by date, grab the 3 newest items), all of the items in the container are inflated. This is because sorting is done outside of the database, and so that you can have the correct indexers (postings.Item("NewsArticle")).
As a best practice for MCMS 2002, to provide the most intuitive and efficient use of your container hierarchies, it would make sense to construct galleries that would reflect different business tasks or departments which may be using these resources. This will contribute greatly to your content contributors, editors, and template designer's ability to reference known locations of resources, but also ensure for a more efficiently designed hierarchy, directly allowing for the best possible performance of the system. Typically having more than 300 items in a container does not allow for either of these.
By having an excessive amount of objects (resources, pages, etc), in any one particular container (galleries, channels, etc), you're going to slow down the experience of displaying the contents of any one particular container in the Site Manager. This action of asking the server to display objects in the container can affect the overall performance and state of the server. Once the first request has been made to display the items in a container, as long as the user does not close Site Manager, they will be able to make subsequent requests to show the contents much faster as the contents are cached for this session.
Note: there is a whitepaper that discusses performance of MCMS 2002.
I have implemented ASP.NET output caching in my MCMS Template with VaryByCustom="CMSPosting;CMSRole"
When does MCMS get the users MCMS role? Each time the posting is requested? Only one time after the authentication process?
The user’s role membership is calculated one time only when they first authenticate and the MCMS auth token is generated. During logon all rights groups the current user is in are added to the CMS auth token. After that point, the role membership checks are done against this generated auth token. This means that if the user’s role membership changes after the auth token is generated, this will not have an effect until the next time they authenticate and a new auth token is generated.
Output Caching using CMSRole compares the role information in the auth token against the roles of the item in the cache and returns the item only if exactly identical rights group assignments are on the item in output cache. Otherwise a new instance of the items with the rights groups of the current user will be added to the cache.
Since I'm using the .Text property of the HtmlPlaceholder object I experience performance problems. Is this a known issue?
Yes. The implementation of the .Text property is done in a Single-Threaded Apartment (STA) COM object that suffers from serialization problems.
A workaround (or better way) to get the Text content is to use the following code:
public string StripHtmlTags(string source){ string strRegExp = "<(.|\n)+?>"; Regex r = new Regex( strRegExp, RegexOptions.IgnoreCase | RegexOptions.Compiled ); string strNoTags = r.Replace( source, "" ); return System.Web.HttpUtility.HtmlDecode( strNoTags );}
I am experiencing poor performance on my MCMS server. What could be causing this?
You need to ensure that you are properly testing and developing the site for performance.
First, you should see where you are currently. Use a tool like WAST or ACT to generate load on your machines. Analyze the trace files and make a profile that looks realistic. (i.e. home page hits, searches, car page hits, etc.) Run the profile and see what pages are taking a long time.
Setting the server to be read only will help somewhat, but if the majority of the time is spent actually executing the template code (as opposed to Microsoft® Internet Information Server [IIS] parsing the template, etc.) then the performance gain will be minimal.
Have you considered adding another server to your cluster?
Investigate these questions:
There is no magic bullet that will make their site perform. You need to gather information first to see where you are currently. Perhaps you are already serving out 60 pages views / second on a PII 300. (doubtful, but you get the idea). If so, they will probably need to add hardware / additional servers to the cluster.
The only information here is that some unknown site running some unknown code is doing a lot of processing. This will probably take a while to track down and decide on the correct course of action, with the easiest answer being "throw more hardware at it". Probably not the correct answer, but the easiest one.
If the performance counters show many Cache misses increase the node cache size.
Note: there is a whitepaper regarding MCMS performance.
I need to store 10000 postings in one channel. I have heard there is a practical limit of 300 items. Which performance impact Would I expect if I still would store 50000 postings in the channel?
There are a few problems, all of which are quite disabling.
First, URL transformations will be slowed down tremendously. Instead of iterating over 50 - 400 items to find the one you need, CMS will iterate over 5000-10000. Each of these items gets added to the cache, which means that the cache will generally become less effective (if you have a 20000 item cache, and you have 10000 postings in a channel (each one consisting of both an item for the posting, and an item for the content), you will blow out your cache each time you hit any page in that channel).
As well, any time you access any item in that collection by any method other than GetNodeByGUID, CMS will load the entire collection into memory in order to sort it, security trim it, etc. This means that again, you blow out the cache, and you also tend to consume a lot of memory for this session (CMS wraps each of these objects in a user API object, etc.) It also takes time to load, sort, etc.
Finally, the majority of the UIs are not implemented with this usage in mind. E.g. they do not support paging of data, etc. Bottom line:Higher memory consumptionMore database activityLower cache hit ratioslower runtime performancepossibly unusable UI pieces due to the amount of data that would need to be displayed (such as picking a posting to hyperlink to in the hyperlink dialog box)
I have a navigation control that is used on my channel rendering script and on most of my postings. This navigation control renders identical content for all items in a channel. Now I would like to increase performance by using ASP.NET output caching. I can see that MCMS provides the ability to cache user controls at the Posting level. Is it possible to do the same on the channel level? I would like to have only one instance of the control per channel in the cache and not a new one for every posting.
MCMS does not provide this functionality out of the box. But you can easily implement it on your own by doing the following:
Add the following method to your global.asax.cs:
protected override string GetVaryByCustomStringToken(HttpContext context, string token) { if (token.ToLower() == "cmschannel") return CmsHttpContext.Current.Channel.Guid; else return base.GetVaryByCustomStringToken(context, token); }
This adds a new custom string token (CMSChannel) to the cache evaluation and guarantees that the same cached instance of the user control is used for all postings and the channel rendering script in the same channel.
You now have to add the token to the user control as follows:
<%@ OutputCache Duration="300" VaryByParam="None" VaryByCustom="CMSChannel;CMSControl" %>
Can anyone comment on how many threads should be used to simulate client requests against a standard dual-processor MCMS server? It is also using Commerce Server and SQL Server on the backend server.
Testing MCMS will be very similar to testing any other web application. Ideally, you want to simulate the entire user environment to test the system. (i.e. there are 16 typical types of users, and this is how they normally view the site, click, click, pause, click, pause, click click click). Increase the number of users until the site breaks or it takes too long to get a page. We use Web Application Stress Tool (WAST) or Application Center Test (ACT).The ideal scenario is to have lots of threads with a long random delay. This will tend to simulate reality better than a few threads. However, to properly do this, you need a lot of client machines, and you need to run the test for a long time (if you wait 2 - 7 seconds between requests, you will need to run a lot of clients to get a decent load, and you will need to run for 20 or 30 minutes to get a decent average. If you are testing specific pages/templates during development, this is not feasible either.What we tend to do is select a small number of pages (10 or so), and run them for a minute at a time, with 10 seconds warm-up and cool down. On a dual processor machine, 4 threads will probably give you the fastest numbers, while 20 or 30 threads will probably give you a better idea of what will actually happen under load. Again, for ease of use ,we tend to turn off the delay. With a delay, you will need to run the test for much longer.
ASP only allows 25 threads / CPU to be active at any time, so 200 is kind of pointless. If they have a delay involved, then check with perfmon to see how many ASP requests are currently active, how many are waiting, etc.If it is a developer that is trying to find specific hotspots, take 20 threads or so and no delay. If they are testing the entire site to make sure that they can meet specific goals set forth in a specification, then they need to try and simulate the real environment as much as possible, meaning lots of threads, lots of delay (and lots of client machines to drive WAST or ACT).
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2004 Microsoft Corporation. All rights reserved.
Microsoft, ActiveX, Visual Studio, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
