Tuning ERP systems for peak performance

Unit, integration, and stress testing ensures enterprise resource project implementations.


You Can't Detect What You Can't See: Illuminating the Entire Kill Chain

On-Demand Webinar

(Page 1 of 3)

In many companies, enterprise resource planning (ERP) systems constitute the engine upon which new business processes are deployed. And ERP implementations are usually part of a broader enterprise computing effort involving the integration of Web, server, and host-based applications. These business transactions are essential elements in the drive to deploy new products and services and support new customer relationship management efforts.

ERP system users are only concerned about the time it takes for them to accomplish specific tasks. They're not concerned about the internals of the system and how many millions of operations per second a server can handle.
With so much resting on these systems, it's imperative that they operate at peak performance. IT departments need to adopt measurements for tracking the performance of their ERP applications both during implementation and production phases of operation.

Companies that deploy these complex, The rate at which these applications are deployed by organizations, the pace at which data grows, These factors also influence the application architecture adopted to support large-scale ERP deployments.

Any type of performance evaluation should include extensive stress, system integration, unit and parallel tests to examine every facet of the system and how it performs in relation to the underlying infrastructure. That means testing should be addressed at every stage of the ERP project--from pilot deployment to full blown rollout. Tests should also be performed after lifecycle changes and software upgrades are made to the system.

There are nine basic steps used to evaluate and measure the performance of an ERP system:

  1. Definition of performance requirements including minimal acceptable response time for all end-to-end tasks and acceptable network latency of an interface.
  2. Creation of a test bed with all components in place.
  3. Configuration of entire infrastructure based on vendor recommendations.
  4. Execution of unit tests for each application in the package to ensure all required functions work.
  5. Execution of integration test to ensure compatibility and connectivity between all components.
  6. Launch monitoring tools for underlying systems including operating systems, databases and middleware.
  7. Creation of baseline reference of the response times for all key tasks when the system is not under stress.
  8. Creation of baseline reference of response times for all key tasks under varying load conditions.
  9. If requirements are not met, make necessary changes in the hardware, software and networks and repeat the tests.
A full blown stress test means that the functionality of each ERP software module has been tested in isolation (unit testing) and in conjunction with each other (integration testing). All individual components should be working in isolation and in relation to one another for a successful stress test to be accomplished, since both the functionality and the integration between these components are exercised heavily during a stress test.

When embarking on a detailed test plan, it's important to look at the system architecture and how it influences the ERP deployment and system performance. The following is a list of the architectural components associated with a large-scale Web-enabled ERP implementation:

  • Back-end network infrastructure such as fiber-based storage area network, clustered storage area network, or high speed backbone
  • Scaleable servers such as symmetrical multiprocessing and NUMA systems
  • Back-end software components such as databases and middleware
  • Back-end connection
  • Client hardware
  • Client software
  • Client-side ISP connection
A typical connection flows from the client machine running the OS and browser to the back end via a virtual private network provided by the ISP to a Web server connecting to the application server, and finally connecting to the database server. Performance issues and bottlenecks can stem from any of these connections or from a component and the interface with which the component interacts.

Page 1 of 3

1 2 3
Next Page

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


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



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.