Designing processes - EMC Community Network
Designing processes - EMC Community Network
Designing processes - EMC Community Network
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Performance and Scalability<br />
Skill-set matching<br />
Skill-set matching is another feature that, if not used wisely, can lead to system performance issues.<br />
There are two reasons for system performance issues.<br />
First, skill-set matching involves row-by-row processing where every task that returns in a task list is<br />
evaluated against the user’s competency. This is a drain on system resources.<br />
Second, skill-set matching does not use task list database query language (DQL) optimizations.<br />
Without skill-set matching, a task list brings back the first 100 to 300 tasks. This means that the data<br />
list generated requires less resource consumption and performs faster. To bring back the tasks to the<br />
user when the system matches user skills against tasks, it requires the whole data list.<br />
This means that all tasks are sent to the application server for evaluation against the skill-set. If a task<br />
list contains 10,000 tasks, it brings back 10,000 tasks. Even if the user matches one task out of 10,000<br />
the system still brings back 10,000 tasks, which takes time. A task list with 10,000 tasks that does<br />
not match skill-sets brings back 100 to 300 tasks depending on the number of SDTs involved. It is a<br />
best practice to calculate a baseline timing of a task list before implementing skill-sets. This baseline<br />
calculation enables you to determine how skill-set matching impacts performance. It is important to<br />
realize that performance costs grow as the number of tasks grow in a task list. For example, a task list<br />
that returns 100,000 tasks is unusable.<br />
Logins<br />
The user login operation takes 2 seconds to 10 seconds to complete. The variable that most influences<br />
the login time is the landing tab that opens after a user logs in. If the client prefers a fast login, then set<br />
the landing page to the default page or to a blank search page. However, if the user has a preference<br />
about the tab, then the time to log in can take longer.<br />
Recommended application server settings<br />
<strong>EMC</strong> recommends using the following application server settings:<br />
Recommended Java Flags for a tomcat server<br />
JAVA_OPTS=-server -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -XX:+UseParallelOldGC<br />
Server flag (-server) explanation<br />
JVM server mode provides better performance for long running tests. This must be the first flag.<br />
Permanent generation (-XX:MaxPermSize) explanation<br />
The application dynamically generates and loads many classes expanding the space in the heap to<br />
accommodate its reuse.<br />
Parallel garbage collection (-XX:+UseParallelOldGC) explanation<br />
This allows the JVM to use parallel garbage collection for the full collections.<br />
JVM Capacity<br />
Heap size and threads control the number of users the JVM can support. A JVM can accommodate 150<br />
to 300 users per instance depending on the user activity footprint (opening large forms can reduce the<br />
number of users) and throughput (how fast they are trying to finish the tasks). Response times degrade<br />
as more users enter the JVM. The degradation is due to non-availability of free heap space and users<br />
waiting for available threads. <strong>EMC</strong> recommends a 1024 MB heap. A heap size smaller than 512 MB<br />
100 <strong>EMC</strong> Documentum xCelerated Composition Platform Version 1.6 Best Practices Guide
Change language