Theoretically speaking, the limitations of a model created with the Designer are purely technical, and the resulting performances are generally related to the following topics:

• The physical memory of the server
• The servers’ CPU
• The memory allocated to the Java Virtual Machine
• The number of servers in the cluster
• The number of simultaneous users
• The mean duration of a session
• The bandwidth of the network

In order to determine the performances of your application, it is typically necessary to perform benchmarking. The benchmarking process will allow you to identify the response times on a particular setup, as well as possible problem areas.

Definition:

A benchmark consists of a set of conditions in which the Configurator performance test is conducted. These conditions contain hardware requirements (machines, network), software requirements (application version) and functional requirements (the exact Designer model to be executed).

In order to optimize performances, you can gradually change one parameter of the benchmarking environment or in the benchmarked model at a time, until sufficient response times have been achieved.

Before starting to model however, a certain number of additional modeling practices should be taken into account. Some product govenor limtis exist - See the Governor Limits topic on Connect. You will need to conduct benchmarks in order to ensure that your response times are acceptable.

Warning:

The response times which are noticed by the end-user are dependent on the following elements:

• The initial loading time: the time necessary to fetch an object from the Designer repository or cache and to create an instance of it in the user session.
• The time needed by the CPQ Engine to set values, to execution the propagation cycle, to execute events, etc.
• The time necessary to send the data calculated / issued by the Configurator to the client user interface.
• The time necessary for the browser to visually construct the user interface.

When the benchmark shows a problem in a particular area, you can undertake certain actions. The following paragraphs show an overview of these actions.

We have explained the principle behind loading in the previous sections. If the loading time for a root Configuration Process is too high, the sources can be the following:

• The user interface (or client application) loads the whole Configuration Process at once
• Some BRC are not positioned on the correct object/level
• Some BRC point to a lot of objects “at the bottom” of the configuration

  Tip:

  • When creating a “custom-built” user interface, it is recommended to have it load the various modeling objects incrementally by implementing a “lazy loading” policy.
  • When assigning BRC to objects, make sure that they are positioned on the lowest common ancestor. If BRC are put higher in the hierarchy, they will be loaded sooner, and thus they might load a part of the model needlessly.
  • If certain BRC positioned “high” in the model contain a lot of CPE which reference objects “low” in the model, these BRC might end up loading the full model. In this case, you should consider setting the “autoload” flag to false.

The node Configuration Process access time is too high

The access time to a node Configuration Process is essentially due to the following sources:

• The number of Configuration Processes in the model
• The number of forms in it
• The number of BRC attached to it

  Tip:

  Make sure that the number of form properties inside a form is not too high. Forms containing more then, approximately, 25 form properties cover very often multiple issues, and are thus not necessarily atomic.

  Warning:

  A form is called atomic when it treats one and only one functional area. An atomic form can typically have a lot of dependencies between its own form properties. However, the number of dependencies pointing to objects outside the form should be as little as possible.

The access time to a form can be due to a certain number of sources:

• The number of form properties in it
• The number of rich media objects called by the form or its form properties
• The BRC loading time (c.f. next paragraph)

  Tip:

  Make sure that the number of form properties inside a form is not too high. Forms containing more then, approximately, 25 form properties cover very often multiple issues, and are thus not necessarily atomic.

  Warning:

  A form is called atomic when it treats one and only one functional area. An atomic form can typically have a lot of dependencies between its own form properties. However, the number of dependencies pointing to objects outside the form should be as little as possible.

The BRC loading and execution times vary in terms of:

• The number of BRC attached to the form or to its form properties
• The BRC format
• The BRC size
• The number of objects called by the BRC (e.g. standard items)
• The number of aliases

Therefore, the following practices are recommended:

Tip:

• Make sure that the type of BRC is optimized: prefer matrixes whenever possible.
• Make sure that the BRC content is as lightweight as possible: prefer simple types (text, number, etc.) over object types (business values, standard items). The latter will inevitably be “bigger” because they contain more information (translated descriptions, rich media objects, etc.).
• Make sure that the BRC is semantically speaking normalized: there should not be any more aliases then needed.

Please watch out that, when your model evolves, typically you will “add functionality”. Adding functionality means that the CPQ Engine needs to treat more data and more functions; this will inevitably have an impact on performances. The same goes off course for your model.

Tip:

Do not hesitate to repeat your functional and performances tests and / or to re-perform benchmarking when your model evolves.

Warning:

Do not hesitate to re-perform benchmarking when upgrading the CPQ version.

When running your model in a production environment, make sure that the cache is activated. CPQ involves a caching mechanism that automatically loads the objects from the Designer repository in the cache the first time that they are being accessed by a user.

Warning:

For performance purposes, make sure that all the necessary objects in a production version of your model are loaded into the application’s cache.