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 :
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:
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.
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.
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.
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!