Wanted to stop by and see what Jeroen van Rotterdam (XDB genius) and David Louie have cooked-up for XML in Documentum.  Been doing a lot of work here and I want to see growth. XProc is shown as the core of the XML Processing model.  The engine works with the xDB database and uses a [...]

This is the first half of Ed Bueche’s annual performance session.  I’m only going to be posting notes from this half though as I will be presenting during his second session, so if you are attending, send me your notes and I’ll share them with everyone.

• Many of these topics will be covered in the xCP Performance Tuning Guide coming to the EDN
• Suggests taking the Architecture courses to help design and implement the technologies properly. (Good idea for any full-time architects or wanna-be architects)
• Use Structured Data Type’s (SDT) instead of Simple process variables
• SDT=Container of related variables for a workflow process
• Process variables are data elements that are part of a workflow, definition of the variables impacts the underlying data model and the performance
• Simple Process Variables with different base-data types are modeled as separate object types
• Can’t put composite index on mixed repeating / non-repeating attributes, which means separate tables (Only real fix is a union DQL, one that hits the single att & one that hits repeating)
• Using  different SDTs in one process can add limits on filtering and sorting on those different SDTs.
• Denormalizing document names into SDT if needed for task list. In general, denormalize for performance as xCP works with the SDTs quite well
• Make Priority Selective within a Single Queue to improve performance on large queue
• Make sure that the work queues are balanced
• Set undisplayed process variables as invisible in order to speed form rendering, don’t depend on it just not being on the form.
• In general, leverage your WDK and Documentum performance tuning instincts to help when tuning xCP, they will serve you well.
• WDK tips
  • Disable drag and drop and column resizing in the app.xml file, 10-25% performance improvement
  • Disable the preview panel if NOT needed
  • Increase <cache-control> parameter value, reduces browser requests for static content
• In SQL Server, make certain the paramatization config item is set to force, similar to Oracle cursor_sharing
• For user response time>fewer workflow agents and higher polling intervals (30-60 seconds)
• For task throughputs, more agents and shorter intervals
• Watch out for contention on dmi_queue_item between Index Agent items and BPM task items as both are in the same table
• Disable full text indexing if not needed, don’t just turn off indexer
• Be proficient at creating indexers on SDTs
• xCP 1.5 and D6.6
  • Task list and queue list enhancements as well as Task Form loading
  • Global Pagination ensures only 100 rows are being sorted and returned in all scenarios
    • DQL to support result windows
    • A new DQL hint (RETURN_RANGE)
  • DQL Left Outer Join
    • Used instead of Union when joining SDT or simple process variable data
    • Improves ability to handle multiple process variables

Off to my session on a Migration project at Baltimore Gas & Electric. Still need more coffee.  Thinking more sleep tonight would be a good thing.

Disclaimer

All information in this post was gathered from the presenters and presentation. It does not reflect my opinion unless clearly indicated (Italics in parenthesis). Any errors are most likely from my misunderstanding a statement or imperfectly recording the information. Updates to correct information are reflected in red, but will not be otherwise indicated.

All statements about the future of EMC products and strategy are subject to change at any time due to a large variety of factors.

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 »

Share and Enjoy:

It is the holiday season where you should be putting more fun in everything. Rex Lee did a nice blog post, Maximizing Business Value from Enterprise 2.0 through Fun & Motivation. I did a FastFoward post on it but could…