Performance checklist

While it is known that large amounts of objects can lead to performance issues, they are often times not avoidable. A custom implementation can require a large amount of data, with complex entity attributes, and many specs, together with sophisticated business logic. A smart design or arrangement can affect the performance to some extent, and for the remaining, you must deal with them case by case.

Typical questions include, how large is large? and what is the optimal number for different objects? There is no absolute number or standard answer, as the different components need to work together and display unique characteristics for specific user scenarios of specific customer implementation. There is some benchmark data on the volume testing, which can be considered as a general reference.

The following list identifies possible resolutions that can help you to identify the source of your product performance issues:

• User interface response time due to large number of concurrent users. When there are large numbers of users (100+), the appsvr process can be stressed due to:
  1. More processing
  2. More memory consumption (for all the user sessions)
  3. Potentially thread issue
• Import jobs for initial load. Following are the characteristics of initial data load,
  1. Large volume of data
  2. Business validation logic may/may not be turned off
  3. Mostly database writes (much less reads)
  Potential solutions:
  1. Parallel jobs
  2. Check data record dependency
  3. Keep validation logic to minimal
  4. Cache candidate for things to be accessed for most of the items (such as category cache, if the item needs to be mapped under the categories)
  5. Check that the performance bottleneck is in scheduler or at database side
• Import jobs for incremental load. Following are the characteristics of incremental load:
  1. Data volume is less than the initial load
  2. May require more business validation logic
  3. May need more check on existing item/category data
  4. Combination of database reads/searches/writes
  Potential solutions:
  1. Parallel jobs
  2. Optimization of script, potential object/data cache
• System resource sharing between various services. The various services of Product Master on the same box can compete for the limited system resources. For example, while you run jobs, the user interface response time can become slower, due to the processor cycle on the appserver machine, and potentially more loads on the database machine. So if possible, the jobs should be scheduled to run during off-hour when users are not in the system.
• Solution scripts. Many of business logic exists as either script or custom Java™ code (using Product Master Java API) in Product Master. Code optimization is important to improve the user interface or job performance.
  1. Compiled mode,
  2. Get read-only version of objects if script operation supports that option,
  3. Be careful of the interaction/validation with external system,
  4. Potentially cache mechanism to reuse object if frequently accessed,
  5. Profiling the scenario for deep analysis. Sort the methods by where the most time is spent and look for the following:
     1. How much time is being spent (focus on the largest number first),
     2. The number of executions of the method where a large amount of time is spent.
  6. Apply solution-specific knowledge to the numbers.
     • For example, if you know that your import is loading 100 items, which map to only three possible categories, but you are calling getCategoryByPath() 100 times you are wasting processing - if you cached the category you would call this at most three times, despite processing 100 (or even 10 million) items
     • For example, if you see that a particular database query is taking 10 seconds, can you optimize the query (retrieve less data, simplify what it is searching for, use indexed attributes)