Tuning ERP systems for peak performance: Page 2

(Page 2 of 3)

The enormity and complexity of ERP implementation environments can give rise to a variety of bottlenecks stemming from network connections, database locks, memory usage, router latency, and firewall problems. Problems can include any number of the following:

  • Too many software modules installed and cached
  • Outdated and insufficient hardware
  • Outdated and incompatible software
  • Slow modem access
  • Lack of virtual memory or disk space
  • Router latency resulting from too many hops
  • Clogged and insufficient network infrastructure
  • Improper operating system configuration
  • Insufficient database locks
  • Inefficient use of application partitioning
  • Inefficient use of logical memory manager
  • Improper RAID configuration
  • Slow storage sub-systems
  • Components that are not multi-threaded and ones that do not scale across multiple CPU's
  • Efficient use of addressable memory space
  • Lack of efficient distribution of data between disks or storage sub-systems
  • Poor SQL syntax
  • No load balancing
  • Component interaction latencies
  • Interface latencies
  • Underutilized servers
It's possible to add several thousand factors like the ones above that contribute to poor performance. In order to identify critical bottlenecks that slow performance, use the following nine performance measurements steps to finetune your ERP systems :

Step 1:
Define performance requirements

Performance requirements should define the end-to-end requirements that are the most relevant to system users instead of using transactions per minute, or network latency times. For example, the response time of a human resources or financial system should look at the response time from start to finish, and evaluate tasks such as:

  • Posting a job opening
  • Submitting a leave application
  • Ordering goods
  • Adding a new supplier
  • Submitting a requisition
  • Adding an asset
  • Submitting a purchase order
Users of the system are only concerned about the time it takes for them to accomplish specific tasks using the ERP system. They're not concerned about the internals of the system and how many million of operations per second a server can handle.

By measuring the performance of tasks that use all components of the system, an administrator can baseline the application's performance, identify bottlenecks, make changes, and baseline the effects once again.

When defining performance requirements it's important to consider the user input--and manage user expectations. Critical tasks should be identified. Managing user expectations means communicating about the eventual response times for critical tasks and reports.

It's also important to define other performance parameters along with requirements such as a typical workload or peak workload. A peak workload could include 1,000 WAN users and 200 local users, including 20 power users accessing the financial module. The peak period could include 20 batch processes, 10 application domains, 30 queries, and 30 print jobs running on the system. Measuring the response time of each identified task and sub-task with no workload, typical workload, and peak load is critical to measuring and predicting application performance.

Step 2:
Set up a test bed with all the components in place

It's extremely important to establish a test bed that includes all components and is configured as close to the production environment as possible. All enterprise application vendors provide certification information about the platforms supported. For example, a platform supported by PeopleSoft 7.02 includes information about everything from the OS to the servers.

Supported Configuration

A PeopleSoft 7.02-supported platform includes information about everything from the OS to the servers.

DBMS Type and Version: Sybase 11.5.1
PeopleTools Release: 7.02
Server Make and Model: Sun Ultra Sparc/Sparc
O/S and Version: Solaris 2.6
Platform Support Level: Application Server/ Batch Server/DBMS Server
COBOL Compiler: Micro Focus 4.1
C Compiler: ANSI
Supported SQR Version(s):
Orderable SQR Version(s): Part/VER: 06-P-0655-C-
Tuxedo: 6.3
JOLT: 1.1
Jolt Relay: Supported (Only required if web server and application server reside on separate computers)
DMBS Connectivity:
Other Software: Open Client 11.1.1
Comments: In addition, Sybase is also supported in a three tier environment using Windows NT as an application server
The back-end hardware used in a test bed should be based on the hardware recommendations for a production environment. If a gigabit switch is used on the back end to speed up data transfers between the application server, database, and the interfaced system in the production environment, a similar one should be set up as part of the test bed.

To simulate wide area network and Internet traffic, client machines need to be configured outside the router that connects the back-end network to the WAN or the Internet. If access to the application is expected from client machines with 64MB of memory, a 1300MHz Intel processor, and a 56KB modem, this combination of hardware for the client side should be included as part of the test bed.

Prior to configuring and tuning, the test bed should have sample data, test-monitoring tools, and test-automation tools. These include a protocol analyzer, a test automation tool, operating system, and monitoring tool.

Step 3:
Configure and tune the entire infrastructure based on vendor recommendations and certifications

Before beginning any testing, it's important to configure and tune the entire infrastructure--but only on given parameters and variables. Use the vendor's recommendations as a baseline. It's impossible to get recommendations for all parameters on each platform --even if it is possible, this could introduce unnecessary complexities given the thousands of variables that can be tuned at each layer.

Certain key recommendations include: total memory configuration for the database, total allowable locks, network packet size, number of I/O demons, number of application domains, buffered I/O size, customized cache configurations, recommended OS patches, recommended client connectivity tools version, and patches and network interface card throughput.

Any tests attempted without configuring and tuning to the vendor's specifications is basically a wasted effort. Baselining response time without the default product configurations can lead to misleading test results. However, also note that that configuration and tuning guidelines given by the respective vendors can only act as a starting point. Further changes in specific hardware and software configuration that can improve performance will be dependent on any additional findings based on the remaining steps associated with this process.

Keep in mind that Steps 3 through 8 are iterative processes that must be repeated until the performance requirements are met!

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.