If you have made an investment in Open Text Web Solutions (formerly RedDot) Web Content Management products, you’ve undoubtedly experienced performance issues. While every software requires tuning, RedDot is especially susceptible to mis-configuration and poor performance as the out-of-the-box installation comes untuned and ready for Development Environments only. To download the complete white paper please visit: http://www.oshyn.com/landingpages/performance-tuning-open-text

1. Performance Tuning Open Text
Web Solutions Management Server
and Delivery Server
July, 2009
Authors: Christian Burne – Technical Architect,
Shawn Simon – Enterprise Architect,
Gaurav Bhatt – Technical Project Manager,
Julio Canadas – Senior Developer

2. Performance Tuning Open Text
Web Solutions Management Server
and Delivery Server
Table of Contents
Introduction 3
1.0 Optimization Concepts 3
2.0 Web Solutions Management Server 4
2. 1 Architectural 4
2.2 Development Best Practices 4
2.3 Configuration 5
3.0 Web Solutions Delivery Server 7
3.1 Architectural 7
3.2 Development Best Practices 8
3.3 Configuration 8
4.0 Web Server Tuning Activities 10
4.1 Architectural 10
4.2 Configuration 10
5.0 Conclusion 11
6.0 Closing 11
About Oshyn 12
About Christian Burne 12
About Shawn Simon 12
About Gaurav Bhatt 12
About Julio Canadas 13

3. Introduction
If you have made an investment in Open Text Web Solutions (formerly RedDot)
Web Content Management products, you’ve undoubtedly experienced
performance issues. While every software requires tuning, RedDot is
especially susceptible to mis-configuration and poor performance as the out-
of-the-box installation comes untuned and ready for Development
Environments only.
This white paper will provide some essential best practices for setup as well as
some tactical steps for configuration which can be taken to optimize your CMS
Server and Delivery Server environment.
1.0 Optimization Concepts
There are some basic categories that optimizations fall into for Open Text Web
Solutions:
1. Architectural -- of servers, distribution of responsibility, clustering
-
2. Development Best Practice -- things you can and should do during
-
Template and Dynament Development
3. Configuration -- tuning parameters for web servers, application servers
-
and CMS servers
Each of these will yield a different performance benefit depending on the types
of features you have on your site and what elements of your architecture they
strain.
The single biggest recommendation we can make, however, is to TEST
your environments before you go live using automated Load Testing tools
such as HP Load Runner to find where the performance bottlenecks are.
environment
This also implies that your Load Testing envir onment is SEPARATE BUT
IDENTICAL to your production environment for valid, controlled testing.
The following is an introductory compilation of general Performance Tuning
activities that should be done in your Open Text Web Solutions environment.

4. 2.0 Web Solutions Management Server
2. 1 Architectural
For CMS Architectural items, here are some of the things you can do:
Activity Effort Descriptions
Clustered Database Hard Management Server is crippled without its database and there is
a high degree of database traffic. It is crucial to have a clustered
database system (either MSSQL Cluster or Oracle RAC).
Separate Publishing to a CMS Medium Publishing process takes up significant resources. This can be a
Server large drain for end users. Consider a dedicated Publishing CMS
Add additional Editing Servers Medium Additional servers can be dedicated by project or multiple per
and Load Balance project and Load Balanced between to scale your editing
environment
2.2 Development Best Practices
There are many Best Practices for Template development in RedDot, however,
these are some that are related to Performance of the system in SmartEdit and
publishing time.
Activity Effort Descriptions
Don’t use more than 3 Hard If you have too many, the connection between PageBuilder and
Navigation Manager Calls .NET starts to degrade
Use .NET for any PreExecution Easy It’s a decision that must be made at the beginning of a project,
and Plugins instead of ASP but it’s essential to a high performing SmartEdit environment.
Create CSS and JS as Assets in Easy One or more of your developers may want to make the CSS and
Asset Manager instead of JS into Content Classes so they can make background images
Content Classes editable. DON’T GIVE IN! The performance degradation incurred
by having the PageBuilder create these (possibly multiple CSSs
and JSs) for each page request in SmartEdit usually isn’t worth
the benefit of being able to edit the background and logo images.
Only put what you need in the Hard This can be as simple as a few <render> tag blocks so that you
current mode only display code in SmartEdit that is necessary (maybe Editors
don’t need some AJAX to work). You may even take this as far as
to create a ‘‘SmartEdit’’ Project Variant to completely separate the
editing interface from the Published interface.