MCMS Performance - Best Practices

Hardware	To avoid competition for resources among applications, it is important that you keep MCMS on dedicated servers. Instances of SQL Server should be installed on their own computers as well. This will avoid the applications and services competing for CPU and memory. Memory Sufficient memory to store the working set of pages in output or fragment cache. Speed up the page assembly - ensure that there is sufficient memory available for the node cache. Processor capacity Ensure that enough CPU capacity available to efficiently assemble pages using data from node cache, disk cache, and the MSQL database. Network Ensure that the Web server is placed on the same switch as the database servers to minimize network latency.
Caching	ASP.NET Output Cache Output caching increases performance so dramatically, all MCMS sites using ASP.NET should make use of this cache where appropriate. This is managed by .NET framework. Fragment Cache This is similar to Output cache, but managed by MCMS. Fragment caching is used only with "guest" content. Fragment caching user-specific content requires a great deal of care to ensure that sensitive information is not accidentally revealed. This only exists for ASP based templates MCMS Node Cache Node cache plays a central role in page assembly - increasing the amount of memory available to it is an important part of improving MCMS performance. To set the node cache depending on your site check set the node cache size based on site size. Disk Cache You should increase the size of the disk cache so that it can contain most, if not all, of your MCMS managed resources. To know more about Caching read Enhancing Performance with Caching.
Navigation	Render only what is necessary. Make the site-level navigation as generic as possible. Use output caching when ever possible.
Authentication	The sites require authentication perform 15% (for basic templates it's around 30%) slower than those require no authentication - remove the authorization module if no authentication is required - this will increase the performance of the site be 10%.
Resource Management	Make resources as minimum as possible to increase the performance of the site. Resources such as images, sound clips, and video clips can have a large impact on your Web site's performance. As a general rule, you should avoid using large resources. Compress resources whenever possible. For example, for pictures, use .jpg images instead of .bmp images. Also, unmanaged resources are not part of MCMS, you can achieve performance improvements by using them.
Content Updates	The affected nodes will be invalidated. If you are using the AddValidationCallbackAllCmsContent method then it will flush the output caching. So it's better to make batch content updates as much as possible.
Background Processing	Database performance will decline during background processing. Therefore, as a general rule you should schedule background processing for non-peak times to reduce the chance that it will affect your site performance.
Managing IIS	On a read-only site, remove HTML packager ISAPI filter.
SQL Server	For optimal performance, the databases should be separated from their transaction logs on different physical drives to prevent resource conflicts. For more information about SQL Server performance tuning, go to Optimizing Database Performance.
Design time Performance	MCMS can handle a reasonably large number of authors (25 to 100), each updating a small number of postings (around 10) per day. However, the performance of MCMS will suffer under a high load of concurrent update operations where the interval between updates is small. MCMS performance will suffer when a live source is coupled with authored content updates.
Placeholders	Limit the number of placeholders on a template to fewer than 100. For best performance, consider limiting the number of placeholders to 30. Limit the line of content to less than 1000. It is better to have less than 100 to have high performance.
Container Hierarchy	Limit the number of containers under the root node. (For example, channels should not have more than 10 to 15 immediate child containers). This won't affect the MCMS performance significantly. But, it will affect the performance of non-MCMS content on the same server. Limit the items in a container to fewer 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.
Custom Property Searches	Design such that, the total number of posting searched using custom property is less than 5000. It is better to have lesser that 500.
Site Partitioning	Very large MCMS sites that contain many postings (which has more than 20,000 postings) should consider whether it is possible to partition the site into a series of smaller sites to get optimum performance.

This is a summary from Performance Planning and Deployment with Content Management Server 2002.

Also Stefan has posted two less known performance issues caused by in-proper use of publishing API in his article.