Jump to: navigation, search


When downloading content, you may encounter issues that are easily resolved. If these tips don't help, please Contact Us, and we will try to send you the file directly.

Downloading Help files

Save the Help file to your local hard drive, and uncompress (extract) it to an empty folder. To open the Help file, open the folder into which the .zip file was extracted, then do one of the following:

  • If there is only one file in the folder, click that file.
  • If there is more than one file in the folder, click the <name of compressed file>.htm file.
Viewing Help files

If, when you open the Help file, the contents do not display in the right window, consider the following:

  • Are you trying to open the file on a remote computer? If so, copy it to your local machine. Due to a Microsoft security update, you cannot properly view a HTML-based (CHM) Help if it is located on another machine on your network.
  • What is your permissions setting? Right-click the file, select Properties from the context menu, look for an Unblock button, and click it.

Sizing Information

Before deploying the Genesys Web Engagement (GWE) solution to your production site, you must estimate the size of solution that will be able to handle the expected user load. Genesys recommends that you download the GWE Sizing Calculator, an Excel spreadsheet that you can use to help calculate the number of Web Engagement Server nodes required for your production deployment.

Click HERE to download the GWE Sizing Calculator. See download tips

The process of estimation starts from input values, usually given in the terms of business operations; for example, daily visit rates, or page view rates. Using some math, and having in mind the workflow that is applied to the input traffic, you can then produce the expected load values in terms of requests per second. Applying these values to the experimentally produced measurements, you can estimate the size of the solution required to be deployed.

Important
The exact deployment architecture and solution size will vary depending on your hardware equipment, and that the deployed system can be fine-tuned to get the best performance on given equipment and with given user load. However, the estimation can give some basic ideas for the deployment.

Input Data for Load Estimation

To estimate the load, you need to know the following data:

  • Average visits rate and page views rate (per hour)
  • Maximum visits rate and page views rate (per hour)

To estimate the Backend disk space consumption, it is helpful to have the following information about the configuration of the solution:

  • Number of business events per page or visit
  • Portion of categorized events

You can use these numbers as inputs into the GWE Sizing Calculator.

Basic Load Estimation

Visits Rate Estimation

Having the maximum or average visits count and page view count per hour (or day), you can get visits rate and visit depth:

  • Visits per second = Visits per hour / 3600 = Visits per Day / 24*3600
  • Visit depth = Page views per hour / Visits per hour = Page views per day / Visits per day

Events Rate Estimation

Having the following input data about solution configuration:

  • Average number of business events (search, and so on) per page – page custom events
  • Average number of user events (SignIn/SignOut/UserInfo) per visit – custom visit events
  • The fact that every visit produces one system event (visit started) and every page view produces two system events (PageEntered and PageExited)

You can now estimate the average event rate produced by user visits:

  • Events per second = Visits per second * (custom visit events + 1) + (Visits per Seconds * Visit Depth) * (custom page events + 2)

Requests Per Second

Assuming that each visit also contains two requests for loading client scripts and DSL, and every page view also contains one request for categorization info:

  • Requests per second = Visits per second * 1 + (Visits per second * Visit depth) * 2 + Events per second

Peak Load Estimation

Having only average values for visit and page views, you can only predict some average load, and, consequently, only an average solution size that will be able to handle such load. However, the user load is not evenly distributed during the day, so you must estimate possible peak load during busy hours.

To cover that scenario, you can take your Visits as the Poisson distributed flow. So, to estimate the possible peak load, you can use the following calculation:

  • Maximum Visits per Second = Average Visits per Second + 4 * SQRT (Average Visits per Second)

Now, having the Maximum Visits per Second value, it is possible to estimate the Maximum Events per Second and the Maximum Requests per Second, using the same approach as for Basic Load, but replacing average visits rate with maximum visits rate.

Load Estimation Example

Visits Rate Estimation

Having the maximum visits and page view rates per hour, you're calculating visits rate and visit’s depth. For example, having the following values:

  • maximum number of visits is 3000 per hour
  • maximum number of page views is 32000 per hour

The estimated visit depth is 32000/3000 = 10.7 pages.

  • Average load: 3000 visits per hour = 0.83 visits per second
  • Maximum load: 0.83 + 4*sqrt(0.83) = 4.5 visits per second

Events Rate Estimation

Given two business events per page, and about 10 percent of visits producing additional events:

  • Average events per second = 0.83*(1 + 0.1) + (0.83*10.7)*(2 + 2) = 37 events per second

Requests per Second

Assuming that every visit generates one request for script and another for data, and every page view generates one request for categories:

  • Average requests per second = 37 events + 0.83*2 + (0.83*10.7)*1 = 47 requests per second

Peak Load Estimation

Using Maximum Visits per second instead of Average Visits per Second, the following values can be calculated:

  • Maximum events per second = 4.5*(1 + 0.1) + (4.5*10.7)*(2 + 2) = 197 events per second
  • Maximum requests per second = 197 + 4.5*2 + (4.5*10.7)*1 = 254 requests per second

Minimum Solution Size

The solution deployed should handle all user input, and have some N+1 redundancy, so the minimum solution size is:

  • Web Engagement Server – two nodes (to allow redundancy and load balancing)
  • Cassandra – three nodes (keep data consistent and allow one node to fail).

For more help calculating the number of Cassandra nodes you need to support data consistency in the cluster, see http://www.ecyrd.com/cassandracalculator/.

Recommended and Peak Solution Size

Given the estimated average and maximum requests rates, you can find the possible solution size from the Web Engagement Server scaling charts (used in the GWE Sizing Calculator).

Web Engagement Server Recommended and Peak Solution Size Graph

Disk Space Usage

Disk space usage directly depends on the event rate in the solution.

Using the previously defined solution configuration:

  • Events for each visit: VisitStarted
  • Events for each page: PageEntered + PageExited + 2xBusinessEvent
  • A single category is applying for approximately 50% of pages views

And assuming that the Backend cluster has 4 nodes and replication factor = 3:

Disk Space Usage Table

Notes:

  • Database sizes shown without effect of Commit Log size (defaults to 4Gb for each node).
  • Disk space required for each node: (Total Size)/4 nodes.

Glossary

Visit – series of page views from the same uniquely identified individual (a visitor).

Average visits per second – service load in terms of customer site.

Request – a single request to the service. A single page view produces a series of requests to the service, including WebEngagement requests:

  • Loading of monitoring script
  • Loading of categorization information
  • Sending the event information back to the Web Engagement Server

Requests per second (RPS) – actual load in terms of service performance.

Useful Links

Refer to the following links for more information about planning a Cassandra cluster:

This page was last modified on January 7, 2015, at 12:11.

Feedback

Comment on this article:

blog comments powered by Disqus