Help center

View helpful articles, tutorials and FAQs on the set-up and configuration

of the FocalScope omnichannel suite, according to best practice.

How to properly operate a self-hosted FocalScope instance

FocalScope is, for the most part, a database layer, and, as such, the performance of the FocalScope application is 99% dependent on the performance of its associated SQL database. Due to the nature of database-dependent applications, the database size and performance can drastically be affected by the following:

  • Increases in the volume of email traffic
  • Additional users being added in FocalScope
  • Additional email accounts being added in FocalScope
  • Increases in business, support, or general communication with customers/clients
  • Enabling of additional features in the application such as Email Processing Rules, Ticket Queues, and SLA monitoring, or by extending the scope of these features by adding more folders and/or users
  • Generation of ad-hoc / scheduled reports on the main application database

Any such (or related) developments place an ever-greater demand on the hardware resources of the hosting server, and if the system is not constantly monitored--and resource shortages preemptively addressed--then degradation of application performance should be expected.

This rest of this article details the best practices for configuring the hosting server as well as operating the system from day to day.

Configuration of the hosting server

The best practices for configuring the application server are the same as for configuring an SQL Server--see the following: http://www.brentozar.com/archive/2008/03/sql-server-2005-setup-checklist-part-1-before-the-install/, http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328 and http://technet.microsoft.com/en-us/library/dd672789(v=sql.100).aspx (for planning the configuration by looking at the resolutions for common resource bottlenecks).


Additionally, observe the following:

Initial server setup

  1. Evaluate your email workload (number and average size of emails per day or hour) and allocate adequate hardware resources to handle the workload
  2. When setting up the hosting server, use tools like SQLIO to benchmark the throughput of the storage subsystem, and evaluate if the server can handle the workload in p.1 (e.g., http://www.brentozar.com/archive/2008/03/sql-server-2005-setup-checklist-part-1-before-the-install/)
  3. Plan for the system to handle peak (not average) workloads to provide the best user experience (e.g., evaluate email traffic per hour, not per day, and take the maximum value to plan for I/O capacity)
  4. For SQL Server and Database(s), follow the known best practices for SQL Server (e.g., http://www.brentozar.com/archive/2008/03/sql-server-2005-setup-checklist-part-1-before-the-install/)
  5. If you are running the application and SQL Server on the same OS, configure SQL Server upper memory limit and leave approximately 15% of the system's RAM for the OS and the application (e.g., http://www.brentozar.com/archive/2011/09/sysadmins-guide-microsoft-sql-server-memory/)
  6. If possible, put the application folder, SQL Server and Database files on different hard drives
  7. On the drive where the FocalScope application folder is located, reserve an amount of disk space equal to 4 times that required by the peak daily email traffic--this is to ensure that adequate disk space is available for FocalScope temporary files and caching

Server maintenance

  1. Use monitoring tools like PerfMon, SQL DMVs, and SQL System Traces to check for bottlenecks related to memory pressure or I/O
  2. Monitor free disk space and set up alerts in PerfMon to warn you when disk space is running out
  3. By default FocalScope doesn't implement any backup strategy for the application database; the DBA is responsible for implementing the backup strategy and maintaining the database using regular SQL server toolkit or any of the available third party solutions
  4. Preallocate space in the application database to cope with daily amount of email traffic without having to expand database files during peak load times

Precautions

  • If possible, avoid writing the monitoring logs/temporary files/databases/etc. to the system drive or data drives
  • Make sure that sampling rates for all collectors and monitors are not too high, and that the amount of data collected is not overwhelming--otherwise the system will go down because as all resources will be consumed by performance logging. SQL Profiler requires special note and attention with regards to this matter

Daily operation of the system

Depending on the production environment, certain disciplines should be observed when configuring application-level features:

  1. Schedule FocalScope reports such as [Number of emails per date] and [Email traffic per month] so that you can monitor email traffic accurately
  2. Set up data archiving and data purging to keep size of the database constant
  3. If you don't have a shadow database for reporting, and plan to run reports on the main database, do so at off-peak hours when system load is reduced. For non-24 hour operations it is best to schedule reports to generate during night time
  4. Use the [Email accounts list] report to detect outdated email accounts, and deactivate the [Schedule this account...] option for those accounts
  5. Configure alerts in PerfMon (for key performance indicators) to warn administrators about low disk space, memory pressure conditions, and I/O bottlenecks

Useful links




Let us help

If you have any questions, or need further support, please don’t hesitate to reach out.