Designing processes - EMC Community Network
Designing processes - EMC Community Network Designing processes - EMC Community Network
Performance and Scalability Factors that affect performance and scalability This section describes the following factors that can affect performance and scalability: • Automatic activities, page 98 • Search forms, page 98 • Task lists, page 99 • Preconditions, page 99 • Skill-set matching, page 100 • Logins, page 100 Automatic activities To improve the performance of automatic activities in your process, make one user (or a small set of users) the performer of all the automatic activities. For example, if you define a user, such as auto_executor, and make that user the performer of all the automatic activities, the runtime execution of these automatic activities increases considerably. For security reasons, only a superuser can select a specific user as a performer for an automatic activity in Process Builder. Search forms A client may ask you to implement a more complex search option in TaskSpace. Even though it can be easy to configure multiple search options, advise the client against doing it. The difference in database performance (and maintenance) between three search options and four is enormous. The best performing applications enable users to complete their jobs with a minimum of actions and choices. Designing search forms that are seldom or never used is not advised. Minimize search criteria Design search forms with as few search criteria and columns as possible. This keeps application performance degradation to a minimum and makes any future scaling of the application easier. Each search criterion requires more maintenance by the database and adds load to the system. For instance, just one poorly constructed search form with many search options and columns can render the application non-operational. Before designing search forms, it is important that you fully understand the business use cases. Wildcard searches Avoid implementing wildcard searches because exact searches are the only searches that scale. All other types of searches involve some form of scanning (index or table), which can hinder the scalability of the database, and ultimately the entire application. It is important to separate what a client needs from what a client wants. The needs of the business should determine how search forms should be designed and used. System performance and future scalability become victim to over-engineered search forms. Articulate to the client the impact of search 98 EMC Documentum xCelerated Composition Platform Version 1.6 Best Practices Guide
Performance and Scalability technology on system performance. In most cases, clients are willing to reconsider a feature that negatively impacts system performance. Mandatory search attributes When designing a search panel, identify the mandatory fields so the user must always enter them to improve performance. Most attributes that are drop-downs or check boxes qualify for this case. Once you make them mandatory, create a composite index on these combined attributes. This ensures all search queries will at least use this index, instead of open-ended searches, to improve performance. Task lists Task lists are one of the most frequently used views in TaskSpace. The best performing task lists limit the number of SDTs and process variables that appear within the task list. Each additional SDT and process variable results in a new query to the database. When several concurrent users are working on the system, these queries add up. As a practical matter, you can consolidate one or more process variables into a single SDT. For example, a task list containing nine process variables takes 10 seconds to 15 seconds to populate the window. The same task list built with one SDT containing nine attributes takes only 3 seconds to 5 seconds. The difference is that the first task list issued nine requests to the database while the second task list issued only one request. (The best way to understand this behavior is to take a single click trace of the transaction). Consider the number of filters that you create in a task list because each filter impacts system performance. You can further improve task list performance by disabling full-text indexing if it is not being used. Refer to Disabling full-text indexing, page 103 for more information. Preconditions Be careful when using preconditions in a TaskSpace application because they inject row-by-row processing into the response time. If there are ten tasks in a task list and there is a precondition defined for the object type, then the precondition fires ten times. Although preconditions provide rich functionality, they can negatively affect system performance. For example, a task queue with preconditions took 8 seconds to 10 seconds to render. Without the preconditions, the same task list rendered in 3 seconds. It is recommended that you take a baseline timing of a task or search form before you add preconditions. After you establish the baseline, the incremental performance cost of a feature can be assessed. Associate a response time or resource cost for each feature request. Then it is possible to calculate the cost and benefit of each feature. Calculate a cost, even if a feature is mandatory. Discuss feature costs together with performance and scalability with the client. To optimize custom action preconditions for datagrid rendering, define scope values for action definitions that use the precondition. Avoid permission checking in precondition classes, since the system will do object full fetches for each data row. If your precondition must do permission checking, consider using lazy evaluation by adding the oneexecutiononly=’true’ attribute in the tag. EMC Documentum xCelerated Composition Platform Version 1.6 Best Practices Guide 99
- Page 48 and 49: Designing the Process 48 EMC Docume
- Page 50 and 51: Designing the Process Inter-process
- Page 52 and 53: Designing the Process In the HTTP I
- Page 54 and 55: Designing the Process For the child
- Page 56 and 57: Designing the Process at or right a
- Page 58 and 59: Designing the Process Enabling repo
- Page 60 and 61: Designing the Process Performance a
- Page 62 and 63: Designing the Process 62 EMC Docume
- Page 64 and 65: Creating the User Interface mind th
- Page 66 and 67: Creating the User Interface Figure
- Page 68 and 69: Creating the User Interface 4. Sele
- Page 70 and 71: Creating the User Interface Figure
- Page 72 and 73: Creating the User Interface Figure
- Page 74 and 75: Creating the User Interface Figure
- Page 76 and 77: Creating the User Interface Adaptor
- Page 78 and 79: Creating the User Interface Figure
- Page 80 and 81: Creating the User Interface 5. Spec
- Page 82 and 83: Creating the User Interface 1. Open
- Page 84 and 85: Creating the User Interface 11. In
- Page 86 and 87: Creating the User Interface Working
- Page 88 and 89: Creating the User Interface 88 EMC
- Page 90 and 91: Monitoring Business Activity • pu
- Page 92 and 93: Monitoring Business Activity (PRS).
- Page 94 and 95: Monitoring Business Activity • Us
- Page 96 and 97: Performance and Scalability System
- Page 100 and 101: Performance and Scalability Skill-s
- Page 102 and 103: Performance and Scalability
- Page 104 and 105: Performance and Scalability If regi
- Page 106 and 107: Performance and Scalability 106 EMC
- Page 108 and 109: Deploying the Application At deploy
- Page 110 and 111: Deploying the Application 110 EMC D
- Page 112 and 113: Archiving the Application • When
- Page 114 and 115: Archiving the Application b. Log in
- Page 116 and 117: Archiving the Application 5. Create
- Page 118 and 119: Archiving the Application h. Select
- Page 120 and 121: Archiving the Application 120 EMC D
- Page 122 and 123: Prototyping overview Prototyping ov
- Page 124 and 125: Understanding the approach to proto
- Page 126 and 127: Create and run the New Account Appl
- Page 128 and 129: Designing the New Account Applicati
- Page 130 and 131: Designing the New Account Applicati
- Page 132 and 133: Design dashboard and add dashlets 1
- Page 134 and 135: Design dashboard and add dashlets 1
- Page 136 and 137: Process Duration alert 3. From the
- Page 138 and 139: Process Duration alert 17. On the k
- Page 140 and 141: Designing the New Account Process -
- Page 142 and 143: Designing the New Account Process -
- Page 144 and 145: Running the Average Duration proces
- Page 146 and 147: Designing the Average Duration repo
Performance and Scalability<br />
technology on system performance. In most cases, clients are willing to reconsider a feature that<br />
negatively impacts system performance.<br />
Mandatory search attributes<br />
When designing a search panel, identify the mandatory fields so the user must always enter them to<br />
improve performance. Most attributes that are drop-downs or check boxes qualify for this case. Once<br />
you make them mandatory, create a composite index on these combined attributes. This ensures all<br />
search queries will at least use this index, instead of open-ended searches, to improve performance.<br />
Task lists<br />
Task lists are one of the most frequently used views in TaskSpace. The best performing task lists limit<br />
the number of SDTs and process variables that appear within the task list. Each additional SDT and<br />
process variable results in a new query to the database. When several concurrent users are working<br />
on the system, these queries add up. As a practical matter, you can consolidate one or more process<br />
variables into a single SDT. For example, a task list containing nine process variables takes 10 seconds<br />
to 15 seconds to populate the window. The same task list built with one SDT containing nine attributes<br />
takes only 3 seconds to 5 seconds. The difference is that the first task list issued nine requests to the<br />
database while the second task list issued only one request. (The best way to understand this behavior<br />
is to take a single click trace of the transaction).<br />
Consider the number of filters that you create in a task list because each filter impacts system<br />
performance.<br />
You can further improve task list performance by disabling full-text indexing if it is not being used.<br />
Refer to Disabling full-text indexing, page 103 for more information.<br />
Preconditions<br />
Be careful when using preconditions in a TaskSpace application because they inject row-by-row<br />
processing into the response time. If there are ten tasks in a task list and there is a precondition<br />
defined for the object type, then the precondition fires ten times. Although preconditions provide<br />
rich functionality, they can negatively affect system performance. For example, a task queue with<br />
preconditions took 8 seconds to 10 seconds to render. Without the preconditions, the same task list<br />
rendered in 3 seconds.<br />
It is recommended that you take a baseline timing of a task or search form before you add<br />
preconditions. After you establish the baseline, the incremental performance cost of a feature can be<br />
assessed. Associate a response time or resource cost for each feature request. Then it is possible to<br />
calculate the cost and benefit of each feature. Calculate a cost, even if a feature is mandatory. Discuss<br />
feature costs together with performance and scalability with the client.<br />
To optimize custom action preconditions for datagrid rendering, define scope values for action<br />
definitions that use the precondition.<br />
Avoid permission checking in precondition classes, since the system will do object full fetches for each<br />
data row. If your precondition must do permission checking, consider using lazy evaluation by adding<br />
the oneexecutiononly=’true’ attribute in the tag.<br />
<strong>EMC</strong> Documentum xCelerated Composition Platform Version 1.6 Best Practices Guide 99