Maintaining or improving the performance of Livelink^® is an issue many organizations will have to face when moving to Livelink^® 9.5. Open Text has documented that the performance of Livelink^® 9.5 may be less than earlier versions. There are many criteria to look at when analyzing performance but the most important is your implementation architecture.

Livelink^® architecture consists of several components. They include:

• Unix vs. Windows Operating System

• Vertical or Horizontal Clustering

• Livelink^® Thread Configuration vs. CPU capacity

• Supporting Applications: Web Servers, Application Servers, Database Server

• Load Balancer Approach

• Livelink^® Index Distribution

Being able to configure all of these items correctly requires extensive knowledge and experience. The current architecture courses available have not been updated to account for changes in Livelink^® 9.5. This article will examine the key issues associated with Livelink^® architecture and provide the insight your organization needs to maintain or even improve your performance.

Architecture Analysis

Syntergy has been providing architecture analysis and performance tuning for Livelink^® for many years. There are two primary areas of Livelink^® that can dramatically affect performance. The first area is the taxonomy configuration within Livelink^®. This includes folder hierarchy, permissions and user/group configuration. The second area is the architecture. This includes the configuration of the hardware, the configuration of the supporting software and the configuration of Livelink^® performance parameters. This article will examine the architecture issues and provide insight into how to decide what is the correct configuration for your environment.

Operating System Selection

The first architecture component that many organizations tackle is the operating system that Livelink^® is deployed on. In the early years it was a given that large deployments required a Unix operating system. With the release of Windows2000 that thinking changed as Livelink^® performed significantly better on it than on Unix platforms. Lately, performance on the new Sparc processors has brought Unix back into the equation. Syntergy's current recommendation is that Livelink^® will perform equally well on Windows2000 or Unix environments. Organizations should select the operating system that they are most comfortable supporting. There are differences in performance on each operating system but the ability to support and be comfortable with a specific environment is the primary consideration.

Hardware Selection

Many organizations wrestle with the question of hardware selection for their Livelink^® environment. In our experience more CPUs and memory are often needed to maintain the performance experienced in version 9.2. The primary issue is whether to scale the hardware vertically by running multiple Livelink^® instances on one computer or scale the hardware horizontally by running fewer instances on each computer and having more computers. Along with this issue is the related issue of the number of CPUs per Livelink^® instance in each approach. While there is no specific answer that will fit every organization the general answer is that you need one CPU per Livelink^® thread with 5 threads per Livelink^® instance. The recommended minimum threads per instance are 3 and the recommended maximum is 6.

Memory

It is always best to maximize memory but that is not always possible. The amount of memory available for each Livelink^® thread depends on your configuration and Livelink^® usage patterns. The question of horizontal vs. vertical scaling is more difficult because it depends on your network performance, load balancer capability and server performance. In general the trend is toward vertical scaling because of the reduced cost but each organization should analyze their specific environment before making a decision.

Supporting Applications

These are as important as the Livelink^® application when considering performance. The key supporting applications are the web server and/or application server and the database server. In almost all cases it is best to have the database server on a separate server. It is critical that the network connection to the database server be as fast as possible. Also, a common mistake that we find is to run secondary applications on the database server. It is critical that these secondary applications do not affect the performance of the database server. It is equally important that the database is dedicated to Livelink^®. Sometimes we see a database server supporting multiple applications that can periodically slow the database response time for Livelink^®. Equally important is to have dedicated Livelink^® servers. Often a secondary application running on the same computer as a Livelink^® instance can dramatically affect the resources available for Livelink^®. Often the performance impact is intermittent and difficult to track down.

Web Server

The web server and/or application server are extremely important in the Livelink^® performance picture. A poorly responding web server can dramatically affect Livelink^® performance. The key to web server and application server performance is to configure these applications correctly. Syntergy has found that there are few critical settings required for optimal Livelink^® performance. As with the database server we sometimes find that web servers can be supporting more than Livelink^®, which affects overall performance.

Load Balancer

There has been quite a bit of discussion about the most effective approach for a load balancer to distribute the load in Livelink^®. The two primary methods are round robin and availability based. Round robin is easy to setup and maintain. Availability based is more difficult to setup and requires specific software to be effective. The more specific the software is towards Livelink^® availability the better. When looking at Livelink^® availability it is best to be able to determine what the thread load is on each instance of Livelink^® as opposed to the CPU load on a particular server. As with many architecture issues related to Livelink^® load balancing tends to vary based on the specific environment in which it is deployed. It is critical that you understand the tradeoffs involved in a load balancer configuration before making a final decision. Given that disclaimer, we do tend to lean toward availability based load balancing as the best solution for Livelink^® but in many cases we have seen round robin work better. A lot of it depends on how availability is being measured.

Index Configuration

Livelink^® 9.5 offers even more index configuration and architecture options. Index partitions in particular are a new feature that must be understood to maximize performance of the indexing process. When discussing index performance the key area is how quickly Livelink^® can process data entered into Livelink^® and make it available in the index. As in the past, distributing the load of the indexing process across multiple machines may be a requirement for large organizations. Finally, the settings of specific index parameters in the Livelink^® configuration files can have a dramatic affect on the index performance. These issues are fairly sophisticated and beyond the scope of this article. The key point is that Livelink^® now has enough flexibility in it's index architecture to provide good performance when indexing data.

Summary

There are many criteria to look at when analyzing the performance of your Livelink^® implementation. Each organization should attempt to identify their current and future performance goals against the expected growth of Livelink^® as a first step in developing an architecture plan. The next steps require expert analysis to determine where improvements can be made to meet those goals. After the updated architecture is in place it is important to monitor your implementation to insure that your users continue to receive the appropriate response times. Syntergy has years of experience assisting organizations of all sizes in theses areas. When it comes to analyzing Livelink^® architecture it is important to use experienced and knowledgeable resources for the best results.