Performance recommendations and guidance is something I receive comment and question on quite frequently, typically in hallway conversation or in passing at conferences - so in the spirit of those occurrences I've decided to compile a quick list of SharePoint performance recommendations that can be conveyed verbally in five minutes or less.
Do limit the number of site collections/content database, I'm adamantly opposed to the "airline booking model" and much prefer what I like to refer to as the "accounting model" of database management, for example, if you know your maximum allowable site collection quota will be 5GB, and would like to keep your content databases at 100GB, logically you can host no more than 20 site collections per database and while this can result in a large number of content databases, you avoid site collection proliferation...with this model you should also take into account growth and set aside 5-10% to support schema changes, etc. *Remember to size your content databases to the desired size as they are created - SharePoint Products and Technologies will provision the content database at xMB and configure growth to occur incrementally at 1MB chunks. A smaller number of site collections in a content database not only benefits efficiency of operations, but can also mitigate the exposure of any locking that may occur within that database to a small subset of users as opposed to a large population.
Caching and Compression
Do consider and encourage site output caching, BLOB caching, and/or HTTP compression where possible - do be sure to closely monitor processor utilization where using HTTP compression.
Windows Server 2008
Do consider Windows Server 2008, the Next Generation TCP/IP Stack brings a number of benefits to bolster performance including receive window auto-tuning, compound TCP, improved routing path detection and recovery, and more. There is a very informative whitepaper available "Enhanced Network Performance with Microsoft Windows Vista and Windows Server 2008". In regards to Windows Server 2008 SharePoint Products and Technologies, check back frequently as I observe our own results at Microsoft.
Do consider 64-bit, the benefits here are too many to detail, but consider larger data processing chunks, larger address space, etc.
Do consider proactively addressing garbage collection on 64-bit machines, custom code and other external factors can potentially litter the address space with unintended assemblies and permanent memory allocations, while most is addressed with "managed memory" you may still experience conditions in which there is a Web server response delay until the buffer can be moved in memory. Depending on the nature of the code you should consider monitoring .NET CLR Exceptions, Memory, and Loading Performance. So you are faced with the decision to either proactively manage consumption through scheduled recycling, or monitor garbage collection activity dynamically and recycle when garbage collection activity has exceeded a pre-defined threshold - of these decisions the former implies configuring an arbitrary memory threshold and the latter understanding your individual requirements based on Web server configuration (I.e. resident services, hardware, load, etc.) which is the preferred methodology since you in effect will maximize the available memory while ensuring your Web servers remain responsive and mitigating availability issues as the result of too frequent a recycle in the case of configuring or designating a threshold.
Wide Area Networks
Consider WAN acceleration to manage traffic generated by satellite or remote offices and/or data replication scenarios.
Adjust IIS timeout settings to accommodate large file uploads by remote users on slow links, VPN, etc.
Storage Design and Database Architecture
Storage design and database architecture are other potential performance bottlenecks, carefully consider database distribution - where clustering, databases should be distributed across two or more instances - and with the underlying storage, provide as many spindles as possible to your data LUNs.
Do consider Kerberos authentication where possible, significantly reducing the number of round trips per page versus NTLM.