Sampling

You can influence the amount of tracing data collected with the sample rate configuration, which is a percentage value used for randomly deciding which PHP requests are fully traced by Tideways and which are not. Tideways uses sampling to keep the overhead of production profiling small.

When Tideways is enabled, it runs on every request. The sample rate then influences if a full trace is collected including calls to frameworks, SQL, caches and other services via HTTP. When no full trace is collected, Tideways still reports the response time of the request and watches out for potential Exceptions and Fatal Errors. This allows you to get a full picture of your project including the full distribution of response times to every endpoint/transaction.

By default the sample rate for full traces is configured at 25% of all PHP requests and Tideways is automatically started on web requests.

When the daemon gets the data from the PHP extension, then it re-samples the traces to keep only interesting traces up to a max limit of traces per minute that depends on your plan.

The following PHP INI configuration variables can affect how sampling works:

  • tideways.sample_rate can be modified to collect more tracing data to be sent to the local daemon.

  • tideways.auto_start defaults to true and can be set to false or 0 to avoid starting Tideways when a web request is run. This allows you to programmatically start Tideways using Tideways\Profiler::start() API.

  • tideways.traces_only_keep_minimum_ms defaults to 0 (meaning all traces are kept) and can be used to automatically discard detailed traces for requests that are fast and you don’t want to keep traces for. This can be used in conjunction with a high tideways.sample_rate to keep only those traces that are slow. Traces that are discarded because of this setting are still recorded for the monitoring statistics.

The next configuration variables control what Tideways does when the random sampling choice starts the monitoring mode of Tideways.

  • "disabled" for not enabling Tideways.

  • "basic" for basic monitoring data such as latency and memory of request, transaction name and error yes/no.

  • "tracing" for enabling the timeline profiling.

  • "full"  for enabling timeline and callgraph profiling.

The INI configuration variables are

  • tideways.monitor is for the monitoring mode and defaults to basic and can be changed to disabled.

  • tideways.collect is for the decision what profiling data is collected and defaults to tracing, can be changed to full.

Enabling tideways.collect=full increases the visibility in your project by always keeping callgraph traces, but this usually increases the overhead of each request by at least 50% and more. In certain cases we have seen overhead of 800% and more when the callgraph Profiler was activated, because the code executed several usually quick PHP internal functions over 500.000 times in the request. Your mileage with the overhead may vary, but setting the full mode is not recommended for permanent use on production. In addition callgraph traces are usually 3 - 4 times larger in size than timeline traces and Tideways may reduce the collected traces per minute automatically to adjust for this.
Still need help? Email [email protected]