Page tree

The Real User Collector component is sized according to the following table:

Real User Collector sizes

Size

Processor

Memory

Disk

Expected volume of traffic

Low

2 vCPU

8 GB

28 GB

900 to 2,000 hits per second

Medium

4 vCPU

16 GB

28 GB

1,500 to 3,500 hits per second

High

8 vCPU

24 GB

28 GB

2,500 to 7,500 hits per second

To understand the ability of a Collector instance to handle the traffic load, monitor its Home page and check the level of packet loss, as shown in the following example page:

Real User Collector Home page

Packet loss — packets that the system receives but fails to process due to system issue, for example buffer overflow.

Broken hits — hits that the system receives but fails to parse due to malformed traffic.

Packet loss indicates that there are gaps in the sequence number of packets read from the capture port of the Collector. When packets are missing, the system cannot trust the data from the related TCP session. Common reasons for packet loss include:

  • Oversaturation of the network interface card (NIC) serving as the capture port
  • High levels of non-HTTP traffic using processor cycles, thereby slowing the reading of packets inside the Collector

If the traffic volume exceeds a given Collector's processing capacity and you cannot increase the resources allocated to it, you can deploy another Collector instance to handle a portion of the load. You can configure traffic inclusion and exclusions rules to channel specific portions of traffic to one instance or the other. Rules based on IP filtering (either client IP or server IP) are the most efficient because they block traffic at the OS level, before any TCP tracking or SSL decryption. However, you can apply host filters and other complex rules if necessary.

Recommendation

Smart taps can filter out known sources of non-HTTP traffic, sparing the Collector from processing such traffic as far as SSL decryption before it can be recognized and excluded. To understand the level of this wasteful activity, monitor the Traffic capture statistics page of each Collector instance. If the quantity of HTTP traffic being processed is less than 80 percent, consider using a smart tap. These devices can be expensive, but they save money by reducing the resource requirements of your Collector instances.