Best practice
LiveServer Setup Best Practice – How To Tame The OpenText Delivery Server
About the Author
This article is based on the blog post here of Danny Baggs. Danny has a strong developer based background and is working for Open Text.
Overview
The way the LiveServer Delivery Server is set up for a development environment usually is as a standalone application without having a front controlling web server. Although this is working for development purposes it doesn’t work within a live environment with several thousand users firing off HTTP requests every hour or minute or even second.
This post discusses the best practice of deploying the Open Text Delivery Server in an optimal way alongside a front controlling web server. This article provides a high-level overview of what to set up and how the necessary components work together. Depending on feedback I may post further posts on the details of each step.
After reading this article you will know
- How to set up your LiveServer environment properly to ensure it is scalable, reliable and offers high performance
- Which tools you can use to create dynamic functionality
- How you can tweak your LiveServer to gain some SEO enhancements
How does Delivery Server work and what should you not do
The Open Text Delivery Server is a dynamic web server component that has strengths in coarse grained personalization and dynamic behaviour as well as system integration. All you need to know is where to get your hands on and what to do and what you better should not do.
The Open Text Delivery Server is housed within a Servlet Container. A Servlet Container is not the ideal location from which to serve static content. It handles requests in a way that limits the amount of concurrent requests. This can lead to severe performance issues.
There are ways to mitigate this but it needs quite a lot of Java experience and is still not recommended. Unless you wish to maintain a level of access control over the static content let’s put it simply like this:
Don’t run the Deliver Server as a standalone web server.
Next: What do you need to get Delivery Server running?
Read more »
Related posts:
- RQL development with OpenText Web Site Management Server 11
- Clear OpenText Web Site Management CMS Cache
- OpenText Content World 2011 – Have you registered yet?
About the author:
Markus Giesen is a Solutions Architect and RedDot CMS Consultant, formerly based in Germany. Travelling around the world to find and offer solutions for a better world (in a very web based meaning). He just found a way to do this as part of a Melbourne based online consultant house. On this blog Markus shares his personal (not his employers) thoughts and opinions on CMS and web development. In his spare time you will find him reading, snowboarding or travelling. Also, you should follow him on Twitter! 
Tags: Apache, Best practice, Delivery Server, Helicon, IIS, LiveServer, Performance, SEO, Tomcat, URL Rewriting Discussion
3 comments for “LiveServer Setup Best Practice – How To Tame The OpenText Delivery Server”
Post a comment
Stay up to date! - Get notified about followup comments
If you don't feel the urge to comment but wish to stay in the loop:Just enter your email and subscribe to new comments.
Categories
Recent Posts
Recent Comments
- Joel Kinzel on Clear OpenText Web Site Management CMS Cache
- Fulvio on Render Tags – An Overview
- Romola Chrzanowski on RQL development with OpenText Web Site Management Server 11
- Michael Philipp on How to convert OpenText CMS date values
- Andry Poernomo on Render Tags – An Overview
Recent Tweets
- RT @AirKraft: Transport Canada breakout: they manage 80K pages and 300K assets with WSM(RedDot). Wow! #OTCW 2010-11-11
- The RedDot usergroup session 'Future of WCM' is in National Harbor 7, now. See you there! #otcw 2010-11-11
- RT @yttergren: @AirKraft: Calling all WSM(RedDot) devs: share your solutions on http://bit.ly/bgPIof EVERY solution can win an iPad #OTCW 2010-11-10
- Come to the Solution Exchange session. Enhance your (#reddot) CMS project! Chesapeake 12, 3:20pm #otcw Looking forward to see you there! 2010-11-10
- More updates...
Recent Posts
- Clear OpenText Web Site Management CMS Cache
- OpenText Content World 2011 – Have you registered yet?
- OpenText WSM 11 – Is the “Swan” release going to fly?
- RQL development with OpenText Web Site Management Server 11
- Workaround – Placing red dots inside of OpenText CMS Render Tags
- How to show CMS authors the page status
- Project Database Schema
- RedDot CMS Render Tags – The Ultimate List
- Yo dawg! RedDot CMS pages within pages
Great post, Markus (and Danny). We’ve ended up using a dynament to do our Friendly/SEO URL’ing in our LiveServer projects like this:
RewriteRule ^/(.*) /cps/rde/xchg/bizcom/hs.xsl/redirectHandler.xml?path=$1 [PT,L]
The redirect handler can pull it’s data from an XML document published from the CMS or from Verity attributes on each piece of content.
Also, other architectural configs, we’ve outlined in our Delivery Server Production Buildout Whitepaper
What you missed in this article:
1. Never install with the bundled installer. Always install as WAR and deploy it to an own tomcat.
2. Always run the LS/DS in its own Container. It has a strange/greedy kind of heap management.
3. In high performance environment use an additional reverse caching proxy (i.e. varnish) if you don’t have a cdn.
@Christian
You can get the same without using something stated above. We tend to just publish a text-file containing Apache-Configs like:
Redirect /
onto the server and Include them in the vhost-config.
Regarding your questions:
We built an simple MS/DS framework to construct simple forms (incl. client and serverside validation). The success action then can be any dynament code like sending an email, storing form data to an database or calling a webservice. We recommend to build complexer forms using the spring framework.
Regarding the search I really encourage everybody to get rid of this verity crap and use either an complete external searchengine (like google mini) or connect the engine of your choice (endeca, sol’r, …) via serchengine indexing tasks or the new OpenAPI based connector.
Good points Daniel.
I have been told that OpenText is aware of the strengths and weaknesses of Verity and looking into this to make things better in the future.
And I agree on that note that unless OpenText doesn’t come up with a better product than Verity or a cleaner way to configure and set it up you are better off with the Google Search Appliance or another search engine. For the clients: Ask your RedDot Partner what they recommend.