INFRASTRUCTURE BEST PRACTICES FOR PERFORMANCE Michael Poulson and Devin Jansen EMS Software Software Support Engineer October 16-18, 2017
Performance Improvements and Best Practices
Medium-Volume Traffic 150 to 200 Active SQL Connections CPU Processor and Cores: 3.2 GHz plus 8 cores RAM 8GB SQL Server Hardware Specifications (Based on SQL Server 2014) Storage Space Minimum of 50GB for space depending on use of EMS and archive maintenance schedule (Includes OS) Separate Data and Log files for optimal performance using RAID technology
High-Volume Traffic 200 + Active SQL Connections CPU Processor and Cores: 3.2 GHz plus16 cores RAM 32GB SQL Server Hardware Specifications (Based on SQL Server 2014) Storage Space 500GB + for space depending on use of EMS and archive maintenance schedule
SQL Server Database Optimization Dedicated SQL Instance is highly recommended for better performance in a Medium to Large implementation EMS has a large number of stored procedures and can potentially impact other apps which share the same SQL instance. Instance resources could potentially become divided / locked, which would in turn cause performance issues for any other apps with databases hosted on the shared SQL instance. Data and Log files should be separated for optimal storage performance TempDB Locate on a separate disk/drive Number of data files should equal the number of logical CPU cores, up to 8 plus one Log File. (Divide the total space of the drive by 9 for the size number) SQL Instance Maintenance Defragmentation DBCC CheckDB Update Statistics Manage number of Virtual Log Files This is essentially fragmentation of data log files due to auto-growth
Database Performance Improvement Recommendations Re-Index Database on a regular basis (weekly is recommended) Use a SQL Performance Monitor or SQL Profiler when performance problems occur to identify bottlenecks. Identify long-running or blocking SQL statements and evaluate whether they can be optimized Upgrade the hardware associated with the bottleneck, e.g. adding more RAM, faster CPUs, more or faster Disks, etc. File Placement: Where possible, place the database files, transaction log files, and the tempdb files each on separate, physical I/O devices. This improves performance by allowing multiple physical devices to concurrently service reads and writes to these files. Use RAID 5 or 6 technology for File Placement to improve performance and redundancy (RAID = Redundant Array of Inexpensive Disks)
Web Server Settings Best Practices
Web Application Server Hardware Specifications Medium-Volume Traffic: 15,000 30,000 Active Web User Connections CPU Processor and Cores: 2.0 GHz plus 8 cores RAM 4GB for medium use of 150 to 200 Active SQL Connections Storage Space 1GB or more
Web Application Server Hardware Specifications High-Volume Traffic: 30,000 + Active Web User Connections CPU Processor and Cores: 3.2 GHz plus 8 cores RAM 40GB Storage Space 10GB or more
Web Server Load Balancing Use Load Balancing to keep your EMS web sites up through traffic spikes by combining the power of multiple servers for increased performance Make sure that persistence-based load balancing is enabled (sticky sessions) Alternatively you can separate the applications on different servers, such as putting the Platform Services on a separate application server, or deploy the Room Sign application to it s own server.
Web Site Security It is important to protect data that is used to book events such as Contacts email addresses, phone numbers, and names using the HTTPS Protocol Portal Authentication (Windows Authentication, SAML etc.,) can be used for secure login to your EMS Web Applications
Disaster Recovery and Upgrade Considerations
Disaster Recovery Offsite location of servers Example: If server A in location A goes down due to a natural disaster, you should be able to easily switch over to Server B in location B, which ideally should be in an entirely different city or building. Take into consideration restoration times and data loss with this option. Using the Cloud is another option for Disaster Recovery
Database Backups Recommend Full Daily Backup of EMS database Restoring a full backup that was done a day or night before will not include any data that had been entered from the time the backup was done to the time of restore. More frequent backups will reduce that data loss if you have space available. Keep backups in an offsite location, but quick & easy access Customized Configuration Files Keep a backup of your CSS files for easy access when Disaster Recover and Upgrading Web Application and Master Calendar. Disaster Recovery EMS Academics using the EMS Campus Web Service will need to keep a backup of the Queries.xml file for easy access after Upgrading or Disaster Recovery
Upgrading/Migrating Database and Web Application Servers Transitioning from an old server to a new server (or hosted server) will need consideration of stoppage time. The Campus Web Service (for Academics) will require the default Queries.xml to be replaced with your customized one Keep the web application files (web.config) handy when moving servers in case there are any setting changes that are different from the default version Keep a backup of your CSS files for easy access when Upgrading Web Application and Master Calendar Keep a document that has all the URL s for each of the web applications. IP Addresses that are associated with the URL s that might require DNS entries to change or VIPs/Load Balancers
Application Configuration Settings
EMS Services Configuration Settings Notification Services settings Check your notification interval setting if you see performance start to degrade, or if users state they aren t getting notifications quick enough For Example, if you have a very fast interval setting such as setting your Email Notification Service to send every minute you might start seeing duplicate emails because the processes that are part of the service never get to finish before they have to start again Academic Auto Sync Academic (Campus) Auto Sync intervals are recommended to be at 45 minutes. Setting this to be at a quicker pace can cause performance issues with larger terms You can have the Auto Sync run at a designated time so that a maintenance window won t interfere with a Sync in progress