The Real User Collector component is sized according to the following table:
Real User Collector sizes
|Expected volume of traffic|
|Demo mode||2 vCPU||4 GB|
|NA for Demo mode|
|900 to 2,000 hits per second|
|1,500 to 3,500 hits per second|
|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:
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.
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.