When licensed with a CLOUD-* key, FusionReactor will connect to FusionReactor Cloud and begin shipping metric data periodically.
Apart from numeric metrics like memory and CPU Usage, FusionReactor will also ship certain transactions to FusionReactor Cloud. These key transactions are visible in the Transactions tab, after selecting a server.
Master (also known as ‘parent’) transactions are selected for shipping to the cloud based on a set of criteria buckets. There is one set of buckets per application. Only the first 100 distinct applications are tracked per minute, and there’s also a global limit of 100 master transactions per minute too.
- Error Transactions – the first 4 transactions to close in error (e.g. web requests resulting in 500-series results) are selected.
- Long – the longest 4 transactions which ran longer than 500ms are selected.
- Slow – the longest 4 transactions which were slower than the threshold set in FusionReactor > Requests > Settings > WebRequest History > Slow Request Threshold are selected.
All of the subtransactions of these masters are also kept and transferred (but see the section on Subtransaction Trimming later).
If a transaction is seen which would fall into one of these buckets, but:
- It belongs to the 101st or laster application to be seen that minute, or
- There are already 100 transactions in all buckets across all applications,
… then that transaction will not be sent to the Cloud.
Transactions can have a virtually-unlimited quantity of subtransactions. For example: a ColdFusion page (which is tracked as a parent transaction) can perform a CFHTTP call to a REST endpoint. That call will be detected and tracked as a subtransaction on the CF page. This could happen multiple times and they would all be tracked by FusionReactor.
In order to keep the size of shipped data within an acceptable margin, a culling algorithm ensures that at most, 500 subtransactions are shipped to the cloud.
The algorithm looks at culling subtransactions of the long bucket first, then slow, and then error last. We do it in this order so that the error transactions are less likely to be trimmed because they’re most important.
If subtransactions were trimmed from the shipped data, this will be indicated in FusionReactor Cloud.