Sizing Information
Before deploying the Genesys Co-browse solution to your production site, you should estimate the solution size needed to handle your expected user load. Genesys recommends using the Co-browse Sizing Calculator, an Excel workbook that helps you calculate the number of Co-browse Server nodes required for your production deployment.
Download Co-browse Sizing Calculator
Estimating Load
For Co-browse load capacity planning, use the following input parameters in the Co-browse Sizing Calculator:
- Expected maximum parallel Co-browse sessions
- Website complexity. In the Sizing Calculator, you can select from two boundary options, average (genesys.com) and high (amazon.com). Choose high if your website is highly dynamic, and interactive. For example, websites including a large single-page application, a lot of multimedia content, and/or dynamic page options should select high website complexity.
- WebSocket connection availability
- CPU cores per node, 8 or 4
WebSocket Support
To achieve the best performance, we highly recommend WebSocket support. Genesys Co-browse enables WebSockets by default. WebSocket-based Co-browse sessions appear smoother to users and consume significantly less traffic by avoiding HTTP overhead. The Co-browse server also consumes less hardware resources when using WebSockets and you may require fewer nodes for your Co-browse cluster.
If you use WebSockets, make sure your load balancers, proxies, and firewalls allow WebSocket connections through. Co-browse uses either WebSockets (ws://) or secure WebSockets (wss://) depending on your website instrumentation.
Planning Scalability
Since Co-browse server nodes do not share many resources besides the Cassandra cluster, you have nearly linear scalability from your Co-browse cluster. Each node adds the same amount of capacity to the cluster.
For high-availability purposes, we recommend at least one additional server to handle the load in case of server failure. The Co-browse Sizing Calculator includes this recommendation. The Sizing Calculator recommends no fewer than two nodes, even if the single server capacity can handle estimated server load.
Cassandra Cluster Deployment
Estimating disk space in the Cassandra Cluster
To estimate the disk space consumption by Cassandra, consider the following factors:
- Data size per session - Co-browse records a very small amount of data per session; approximately 180 bytes for the live sessions registry and approximately 240 bytes for the session history. Given that the rate of new Co-browse sessions is one session per minute, the daily amount of space used will be approximately 600 kilobytes.
- Data retention policy - The retention policy for Cassandra is configured and customized through the Co-browse configuration options. By default, live session data is kept for one day, and session history is kept for two weeks. Given the data above, a one session per minute rate results in a database size of no more than 8 megabytes after two weeks. A different data retention policy will give different results, but the order of database size probably will be the same.
- Cassandra Commit Log settings - When estimating the disk space consumption, you must take into account the space used by Commit Log. This log is where any data goes first, and its limits are configured by Cassandra database options. For the Co-browse embedded database, this limit is set by default to 8192 megabytes. For an external Cassandra cluster, it depends on the cluster settings. Also, note that the Cassandra data compaction process requires the free space to be as large as double the database size available.
Based on the above estimates, you can expect that the Cassandra database for Co-browse space consumption will not be more than the Commit Log size (8 GB by default), plus double (16 GB) free space required. Therefore, it can be useful to set a lower Commit Log size.