If too much information is generated that cannot be cumulated by the perfino collector, the system would be overloaded - the perfino collector would not be able to keep up with its consolidation efforts, the database would grow to eat up all disk space and the UI would become sluggish or unusable.

In a correct configuration, a limited amount of distinct information is generated. For the case that the configuration is not optimal, perfino provides an overload protection mechanism that prevents a breakdown by capping various recording types and warning you with inbox messages that your configuration needs to be adjusted.

When an overload cap is reached, the recorded information is not discarded, but no new names are generated and all further information is shown cumulated in a "capped description" node. While total numbers remain correct, insight into recording details is restricted until you fix your configuration and reset the cap counters.

Types of overloads

The problematic data collection types include

• Transaction names

  For example, if each distinct URL creates a transaction with the full URL path as its name and you have a lot of different static resources, then too many transaction names are generated. You should discard the static resource calls because they do not map to high-level business transactions.

• Payloads

  For example, if you have configured to resolve non-prepared JDBC statements separately, and the SQL statements contain non-numeric embedded IDs that perfino cannot extract and replace with ID markers, there will be too many distinct statements after a certain amount of time.

  Another possibility is that your prepared statements contain parameters directly in the statement body and not as bound variables. Such usage of prepared statements is non-optimal and does not work with perfino.

• Remote call sites

  perfino can track inter-VM calls for several technologies, like web services, EJB and RMI. For each such remote call site, perfino has to split its transaction trees and maintain associated information. In VM pools where many VMs call each other, this can lead to excessive overhead if the number of calls grows like O(n^2) with the number of monitored VMs.

Configuring overload protection

Each overload type is configurable separately. Open the general settings, select the "Global Settings" tab and change one of the maximum numbers in the "Overload protection" section.

Next to each overload type, a colored label informs you whether the particular cap has been reached yet or not. For example, if the transaction name cap has been reached, a typical strategy is to change the configuration so that fewer transaction names are created. After that, you want perfino to start counting again from zero. Click the Reset all cap counters to zero button to reset all counters.