As described above, you can set up filters and sampling to specify how much data is collected. A filter specifies by filter name which transactions you want to collect data from. Sampling specifies what subset percentage or number of transactions you want to collect data from.
Filters and sampling works at the root (or edge) transaction level. A root, or edge, transaction is one that is not a sub-transaction of any other (at least, not that the data collection knows about).
So, when using a browser to access a Web application, a root transaction is a URL request when it first hits the server. The filtering and sampling apply at this level. That is, if you enter a transaction filter, it filters on the URL, and if you sample, it will collect only some of the URLs, and discard others. It is all or nothing: it doesn't sample parts of the URL transactions.
If the Web application resides on multiple servers, some instrumented and some not, only instrumented servers "count." For example, if the user accesses the application through Server A which is not instrumented, and Server A contacts Server B, which is instrumented, via a method call, then the method call is the root transaction. Filtering will not work because it uses URLs, not method names, to filter.
Also, if you are using performance tests or schedules to generate profiling data, then the root transaction takes place on the first ARM-instrumented test element to be run. If the entire test or schedule is ARM-instrumented (that is, the Enable ARM Instrumentation check box is selected for the top-level test or schedule element), there will only be one root transaction, and so filtering and sampling will be ineffectual.