We do not have a document that gives an estimated percentage to expect when enabling these component tracking options so ENH REQ has been filed, JEE-6929.
Impact on AppServer
Enabling component technology or tier/app breakdown will not have much of an impact on the appserver, but object tracking can contribute to higher resource usage. Also since Obect Tracking has been revamped in the latest cartridge (5.7.0). In this latest version Object Tracking allows you to enable tracking on the JVM as a whole and optionally turn on tracking per individual request types.
Impact on FMS
Is a greater impact on the FMS more than what is on the appserver. Component tech/tier/app breakdown or ObjectTracking would mean more data is sent to FMS for processing. This impact can be indirectly measured by the no. of topology types. By default FMS limits any single topology type to have not more than 10,000 instances. Users can optionally increase this number but only if their FMS environment has enough resources to handle it. As for no. of instances that’ll get created on the FMS, this cannot be predicted. This depends directly on a customer’s environment and the type of applications they use. A simple web application with just jsps would account for only a handful of components while a request for a complicated application would account for many more. Even then the no. of requests monitored for that application adds to these numbers. We could not easily tell a customer the overhead unless they’d first try it on the environment. It is for this reason that we recommend NOT to enable these properties for all request types, but rather pick and choose the request types they are interested in seeing these details and enable these settings (on the recording.config file) on only those requests.