Installing and running Session Recording requires few extra resources beyond what is necessary to run Citrix Virtual Apps and Desktops. However, if you plan to use Session Recording to record a large number of sessions or if the sessions you plan to record can result in large session files (for example, graphically intense applications), consider the performance of your system when planning your Session Recording deployment.
For more information about building a highly scalable Session Recording system, see Citrix article CTX200869.
Consider how much data you will be sending to each Session Recording Server and how quickly the servers can process and store this data. The rate at which your system can store incoming data must be higher than the data input rate.
To estimate your data input rate, multiply the number of sessions recorded by the average size of each recorded session and divide by the time for which you are recording sessions. For example, you might record 5,000 Microsoft Outlook sessions of 20 MB each over an 8-hour work day. In this case, the data input rate is approximately 3.5 Mbps. (5,000 sessions times 20 MB divided by 8 hours, divided by 3,600 seconds per hour.)
You can improve performance by optimizing the performance of a single Session Recording Server or by installing multiple Session Recording Servers on different machines.
Disk and storage hardware
Disk and storage hardware are the most important factors to consider when planning a Session Recording deployment. The write performance of your storage solution is especially important. The faster data can be written to disk, the higher the performance of the system overall.
Storage solutions suitable for use with Session Recording include a set of local disks controlled as RAID arrays by a local disk controller or by an attached SAN.
Note: Do not use Session Recording with NAS. Performance and security problems can occur when recording data is written to a network drive.
For a local drive setup, a disk controller with built-in cache memory enhances performance. A caching disk controller must have a battery backup facility to ensure data integrity in a power failure.
A 100 Mbps network link is suitable for connecting a Session Recording Server. A Gb Ethernet connection might improve performance, but does not result in 10 times greater performance than a 100Mbps link.
Ensure that network switches used by Session Recording are not shared with third-party applications that might compete for available network bandwidth. Ideally, network switches are dedicated for use with the Session Recording Server.
Computer processing capacity
Consider the following specifications for the computer on which a Session Recording Server is installed:
- A dual CPU or dual-core CPU is recommended
- 4 GB of RAM is recommended
Exceeding these specifications does not significantly improve performance.
Deploy multiple Session Recording Servers
If a single Session Recording Server does not meet your performance needs, you can install more Session Recording Servers on different machines to have the Session Recording Servers work as a load balancing pool. In this type of deployment, the Session Recording Servers share the storage and the database. To distribute the load, point the Session Recording Agents to the load balancer that is responsible for the workload distribution.
The Session Recording Database requires Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012, or Microsoft SQL Server 2008 R2. The volume of data sent to the database is very small because the database stores only metadata about the recorded sessions. The files of the recorded sessions themselves are written to a separate disk. Typically, each recorded session requires only about 1 KB of space in the database, unless the Session Recording Event API is used to insert searchable events to the session.
The Express Editions of Microsoft SQL Server 2017, Microsoft SQL Server 2016, Microsoft SQL Server 2014, Microsoft SQL Server 2012, and Microsoft SQL Server 2008 R2 impose a database size limitation of 10 GB. At 1 KB per recording session, the database can catalog about four million sessions. Other editions of Microsoft SQL Server have no database size restrictions and are limited only by available disk space. As the number of sessions in the database increases, performance of the database and speed of searches diminishes only negligibly.
If you are not making customizations through the Session Recording Event API, each recorded session generates four database transactions: two when recording starts, one when the user logs on to the session being recorded, and one when recording ends. If you use the Session Recording Event API to customize sessions, each searchable event recorded generates one transaction. Because even the most basic database deployment can handle hundreds of transactions per second, the processing load on the database is unlikely to be stressed. The impact is light enough that the Session Recording Database can run on the same SQL Server as other databases, including the Citrix Virtual Apps and Desktops data store database.
If your Session Recording deployment requires many millions of recorded sessions to be cataloged in the database, follow Microsoft guidelines for SQL Server scalability.