Cluster tuning
This section includes tuning recommendations for all clusters, followed by suggestions for monitoring clusters using performance counters and investigating clusters using log queries. The section covers tuning and monitoring for interviewing only (web and phone). Tuning and monitoring for synchronization for personal interviewing, or UNICOM Intelligence Interviewer - Server Admin activities (such as authoring using Build or UNICOM Intelligence Author Server Edition, project activation and management, phone monitoring, data management, and reporting using UNICOM Intelligence Reporter - Survey Tabulation or UNICOM Intelligence Reporter Desktop Edition) are not covered.
Every cluster configuration should be benchmarked and tuned before use. A broad range of settings and configuration can impact the performance of the cluster, including IT department provided settings, network configuration, load balancer setup, and project mix. These settings vary from business to business and can decrease the expected cluster performance. The only way to evaluate the performance of your cluster is to benchmark it under load. This should include load testing, performance benchmarking, stress testing, and endurance testing with defined usage scenarios covering your specific projects and users and defined success criteria.
Setting up a repeatable load test for a cluster with a large number of respondents and different user roles is a challenge that is different for every cluster and customer. It will typically require UNICOM Intelligence Interviewer Load Tool scripting, scripting a user interface load tool, numerous computers to drive the load, and people with different skills to monitor and interpret the results. This section does not describe how to benchmark cluster capacity. However this section does provide suggestions for cluster tuning as a result of previous benchmarking.
Measurement and analysis
Several tools are suggested for measuring and analyzing performance during benchmarking:
▪The UNICOM Intelligence Interviewer Load Tool provides page-to-page response time and particular question statistics.
▪A user interface load tool is usually required for testing user interfaces. The tool provides response times and other custom timers.
▪Microsoft SQL Server Reports are useful to check performance. The reports that are most useful to internal tuning are “Top Queries By Average CPU Time” and “Top Queries By Total CPU Time”. If more information is required, use the SQL Server Profiler to get detailed trace output. However, the profiler has a negative impact on database performance, so use it only if issues arise.
Tuning the load balancing script
See
Tuning recommendations for more information.
Other tuning
Per-project tuning
Each engine has a single database connection for a project. If a single project will have a large number (over 500) of concurrent respondents then updating the database using this single connection might become a bottleneck. Performance can be improved for projects with a large number of respondents by setting the MaxCommandsPerConnection property for the RDB DSC 2. The setting specifies the maximum number of commands that are shared by one database connection for the project. Once that limit is reached, another database connection is created. The suggested value for projects with high load is between 30 and 50 (based on internal testing). Update this value in DPM at Server > Projects > [ProjectName] > mrInterview > MaxCommandsPerConnection.
See
See also