image
CHAPTER
1
Outline of a Structured Tuning Methodology
To a technical person, it is truly an incredible feeling when a system performs flawlessly; this is especially true with an Enterprise Resource Planning (ERP) system. You might compare the feeling to listening to a symphony or the roar of a high-performance sports car thundering down the highway—the simple fact is that things are better when they work and work well.
 
As ERP systems continue to evolve, CEOs, CIOs, and system administrators will continue to push to get as much out of their implementations as they possibly can. Similar to a coach training professional athletes, a system administrator must have a solid execution plan to build, grow, and tune his or her implementations. Just as any athlete has to adapt to win, ERP implementations need to be able to meet ever-changing business requirements.
Tuning an ERP system is a complex process that can be affected by a myriad of factors. It can feel like a giant game of Jenga—modify one part of the system, and you can adversely affect other parts. Change the wrong part at the wrong time, and the whole system comes crashing down.
This book will provide a detailed methodology, or “playbook,” for system administrators. The main thrust of this methodology is a structured way to break down performance problems into smaller parts, identify key bottleneck(s), implement change, and measure the performance effects of these changes. Once we have addressed the primary performance issues, we will expand the methodology to assist system administrators with benchmarking and boilerplating their systems.
image
NOTE
This chapter will review the major components involved in performance tuning an ERP implementation. It will provide a base outline of the low-level concepts that will be reviewed in detail in later chapters.
This chapter provides a glimpse into a structured tuning methodology. It will acquaint you with the high-level components of the tuning process and outline basic overall performance practices. It offers a view of how you can apply these concepts to the layers of an ERP implementation and provides an overview of the major components and technical pillars that can affect performance. Once the basics of the strategy have been detailed, you will learn more in-depth details about the components of the methodology and how they can be utilized to tune your implementation effectively.
Overview
That all sounds great, but how do you take full advantage of your system and ensure that it not only meets the needs of your business but grows with it?
As with any complex problem, it helps to break down an issue into smaller parts:
 
  1.  The first step is to define the performance problem adequately. Without first identifying your performance problem, you are basically flying blind.
  2.  Next, define the scope of your problem. Does the identified problem occur for one user or multiple users? Does the problem occur only under load? Can the problem be reproduced? By identifying the scope of the problem, you can start to define what it will take to resolve the issue.
  3.  Determine where the majority of the processing time is being spent. This will allow you to focus on the proper components of the implementation. You can think of these components as pillars of a Roman building. Performance bottlenecks can occur at any pillar, but by understanding how each interacts and applying a structured methodology, you can identify and resolve performance issues.
 
The high-level components, that is pillars, of an ERP system are:
 
image   User interface
image   EnterpriseOne foundation
image   Interface
image   Database
image   Network
image   Operating system/server
image   Disk
 
Once you have established an awareness of the major components of the system, you can leverage this knowledge to isolate a performance issue. Think of this as first dividing an issue into major groups, then subgroups, and so on. Each of these components can have a major impact on the overall performance and stability of an implementation.
A performance bottleneck can exist in any of the major components. An administrator’s primary goal is to identify where that bottleneck exists and remove it. This process involves not only removing the bottleneck, but ensuring that the problem is not just moved from one part of the implementation to another. To identify and correct a performance issue, you must look at the problems at each pillar of the implementation. When a performance issue is encountered, you evaluate what pillar of the implementation needs your attention. To do this, a structured plan comes in handy.
After defining a performance problem, identifying the scope, and determining what components are causing performance issues, you need to be able to measure your successes or failures. To do this, you need to establish a performance baseline which determines what is considered acceptable versus unacceptable performance. If, for example, a process takes ten minutes, a 20 percent improvement might sound great, but it might not mean much if the true goal is to have the process run in less than a minute. Depending on the problem, you might have to leverage different measures: A long-running SQL query that needs to be tuned may take minutes, or a very quick part of the code that gets called thousands of times can be improved by reducing the number of calls to eliminate a bottleneck.
Next, you can take a first cut at tuning efforts at a high level; macro changes get the system into the ballpark of your performance goals. These changes are implemented at the layer of the implementation where the problem is occurring (such as database, disk, and so on) and are generally larger component changes. Of course, after each change, the system administrator(s) need to measure the impact of the change.
Once the major changes have been made, you can start moving into more micro tuning efforts. These types of efforts will allow you to identify and address reported performance issues. Micro changes are more directly focused on the identified issue rather than on general performance tuning settings. An example might be adding an index to a table to address a specific query that the business requires. Once applied, the identified business process can be benchmarked with the changes in place to provide an accurate measure of the change.
The application of a structured performance tuning methodology not only allows you to identify and address performance issues at the macro and micro levels, but it provides the structure to help you benchmark the process and start “boilerplating” major setting changes. This gives you more tools to address not only performance issues, but also common business drivers in your implementation.
Benchmarks
Now that we have provided an outline of the performance tuning methodology and some general examples of how to apply the methodology, you can begin to develop system benchmarks. This information will allow you to adjust your system to meet your changing business requirements. An example of this might be adding users to your implementation to meet increased business needs. If you apply the methodology, you will be able to identify an average number of users to leverage per Java Virtual Machine (JVM). Once you reach this number, you will know to increase the number of JVMs and/or adjust your kernel processes and other processes to allow for the additional users.
Along with identifying these general performance methods, you can encourage administrators to continue monitoring their systems. This helps create benchmarks for “good” versus “bad” performance. Benchmarking provides you with a feel for the system and helps you understand how changes affect the implementation. In addition, it provides a view of system utilization by the business over time. All of these items are essential to maintaining the performance and stability of your implementation.
Merits of Continuous Performance Tuning
Savvy clients invest large amounts of capital, time, and tears executing performance testing prior to moving into production. This is an important part of the successful rollout of any ERP implementation. But what happens after you go-live? Does that mean the performance of the system is assured and there is no more work to be done? Not likely—just as a professional athlete needs to continue to train, an effective system needs ongoing performance tuning efforts.
These types of efforts may encompass the following:
 
image   Use of automated testing scripts: LoadRunner and Oracle Application Testing Suites (OATS). Identification of key business processes: order to cash, general ledger, and so on
image   The ability to apply and measure load
image   The ability to identify benchmarks for good/acceptable performance: database, CPU, memory and disk I/O
 
So what does all this buy?
 
image   You know how much load your system can take.
image   You can show the effects of changes to the system not only through general testing but also under load/stress conditions.
image   You can effectively automate your testing processes to meet your business needs.
Business Drivers
Let’s take a look at what types of business drivers can affect the performance of your implementation:
 
image   Addition of new divisions
image   Acquisition of new companies
image   Increased business growth
image   Migration of old systems to a new ERP solution
image   New functionality rollout
 
Any of these items can affect how a system operates; it is a good practice and a recommended part of our performance methodology to develop general performance benchmarks to address these and other common issues. For example, you should know how many users access each JVM. After you exceed the threshold (around 85 users per JVM), you might need to add JVMs if you add new users to your system. This, in turn, will require more CPUs and memory. General performance benchmarks help you stay ahead of such requirements and ensure that you have sufficient resources to meet your systems’ needs. This might mean simply knowing when to acquire more disks, or knowing when you need to ask the CIO for another server to accommodate the increased load on the system.
Automated Scripting/Server Manager
So with the new methodology and EnterpriseOne, everything comes ready to go out of the box, right? Not quite. Although you have the base functionality, you need to put your stamp on your implementation. A useful tool to help accomplish this is scripting. Different operating systems support different types of scripting, but the results are the same, improving the stability and performance of your system.
In EnterpriseOne, you can leverage scripting to perform a number of tasks:
 
image   Manage temporary files.
image   Clear log files.
image   Capture key performance indicators (KPIs) such as disk I/O, CPU, and memory indicators.
image   Produce alert messages to operations/support staff.
image   Automate support tasks.
 
In addition to scripting, you can take advantage of the EnterpriseOne Server Manager application that is delivered as part of the standard code line. Server Manager can help to effectively identify areas in your implementation and monitor performance areas in your implementation such as the following:
 
image   Number of users attached to specific kernels (call object)
image   Number of outstanding requests on a kernel
image   Number of kernels defined
image   CPU
image   Memory
Conclusion
This chapter provided a high-level overview of a structured performance methodology to assist you not only in identifying and addressing performance issues, but also in allowing for the development and implementation of key industry practices and benchmarks. As you continue your journey through this book, we will provide more detail about each of the implementation pillars. It is our hope that you are able to leverage the information presented here to tune and maintain your ERP implementation effectively. May your system run flawlessly.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset