In our third Release of 2025, you’ll uncover new ways to correlate data, debug critical bottlenecks, and streamline your workflow.

Over the last few months, we have been working on powerful new features and refinements for you; designed to give you more in-depth visibility, more automation, and smoother workflows.

We’ve added Performance Correlation in our service overview, so you can now spot dependencies and degradations system-wide at a glance.

To make troubleshooting smoother, Tracepoints can now be triggered automatically, along with further improvements that give you faster, more precise profiling results.

For Shopware users, we’re introducing powerful new debugging options for the HTTP Cache, while an improved Transaction Tagging API gives you cleaner, more flexible insights across all environments.

We expanded crawler monitoring for assessment of their impact on app performance.

We’ve also sharpened instrumentation:

– Magento 2 template insights for spotting hidden inefficiencies.

– HTTP Location header instrumentation for more complete visibility.

– Enhanced TYPO3 and AMQP insights, closing gaps in instrumentation.

On top of that, quality-of-life features like choosing the default organization shown right after login make everyday use simpler and more intuitive.

More correlation. Smarter insights. Smoother workflows. With this Release, you’ll be ready to track performance from every angle and resolve issues faster than ever.

Enjoy and see how Release 2025.3 helps you push your application performance to the next level.

Summary

• Correlation In Service Overview
• Trigger Tracepoints Automatically
• Other Tracepoint Improvements
• Debugging Capabilities for Shopware Cache
• Improved Transaction Tagging API
• Monitoring Crawler Impact
• Improved Magento 2 Template Insights
• HTTP Location Header Instrumentation
• Improved TYPO3 Insights
• Improved AMQP Insights
• Select Organization shown after Log-In

Correlation In Service Overview

Through the “Service Overview” feature, Tideways allows you to pinpoint performance issues in different parts of your application. But as these services are often still connected, comparing their performance directly can reveal hidden dependencies and system-wide slowdowns.

With the new ‘All’ option in the performance screen, you can now view and compare performance graphs across all services in your project at once.

Hovering over a timeslot will make the familiar detailed tooltip for that service appear, while the same timeslot is highlighted across all other charts, making cross-service correlations effortless.

• Documentation: Service Overview

Trigger Tracepoints Automatically

Tideways now allows to configure the automatic creation of tracepoints on a schedule for the transactions of a service that have the highest performance impact.

In the Project Settings, you find a new section “Tracepoints” that allows you to configure these automatic tracepoints.

This feature is currently limited to the current request-based plans only and for all these projects, an automatic tracepoint was created already that creates a tracepoint, including callgraph collection, for the highest impact transaction once a day.

Based on this regularly available call graph trace, Tideways can detect more bottlenecks automatically and provide you with fresh insights every day in the “Observations” tab.

Additionally, Tideways can store these traces via Callgraphs in the trace history with long-term retention, enabling you to compare call graph data months or even years apart—and clearly see where your code has regressed over time.

• Documentation: Tracepoint Configuration

Other Tracepoint Improvements

Callgraph Tracepoints Activated By Default

When creating a new Tracepoint, the “Activate Callgraph Profiler” checkbox is now toggled on by default, because we saw the majority of tracepoints were created with Callgraphs activated.

Start Again Button for Tracepoints

A completed tracepoint can now be restarted with the same settings and duration again, by clicking on the „Start again“ button.

Debugging Capabilities for Shopware Cache

For Shopware, Tideways will now also collect the context information influencing the page cache key, making it easier to determine why a specific transaction could not be served from the page cache.

Improved Transaction Tagging API

The \Tideways\Profiler API now includes new methods getTags(), addTag(), and removeTag(). These allow you to build up the list of tags incrementally at different stages of a transaction. For example, adding an “authenticated” tag during bootstrapping and a controller-specific tag later when the controller runs.

The page cache instrumentation, which automatically sets cached and uncached tags, received an in-depth rework. Instead of a Shopware-specific solution, it now includes direct support for Symfony’s HTTP cache, benefiting all Symfony applications and implicitly fixing some bugs within Shopware’s page cache support—for example around stale responses.

The cached and uncached tags added by the automated instrumentation and the Profiler::markPageCache*() methods will also no longer overwrite any other tags already set for the transaction.

• Documentation: Custom Tags
• Documentation: Page Cache Hit Rate API

Monitoring Crawler Impact

Crawlers, bots, and robots have always been an influential source of traffic on public-facing web applications, and with AI bots doing more and more work on behalf of users, this share is increasing recently.

To allow debugging performance issues caused by crawlers, Crawler Detection for traces was added in the 2024.3 Release of Tideways.

In this Release we are expanding its use into Monitoring: You can now see the percentage of crawlers in the current monitoring timeframe as a percentage and in the tooltip for each time slot. You can also see the crawler ratio in the history data at the daily, weekly, and monthly granularity.

Improved Magento 2 Template Insights

Information captured for Magento blocks has been extended. Block events now contain both the name and class name of a block instead of just a block, and new events for rendered template blocks have been added.

HTTP Location Header Improvements

Tideways will now store the redirect target (location response header) as an annotation on the root span.

This helps debugging and understanding in the cases where it’s important to know where exactly a request was redirected to.

Improved TYPO3 Insights

Tideways now includes automated instrumentation for TYPO3, including transaction naming, automated service detection, page cache tagging support, and Fluid Template spans.

• Documentation: Compatibility and Requirements
• Documentation: Supported Frameworks and Databases

Improved AMQP Insights

The existing AMQP instrumentation for both the amqp extension and the php-amqplib/php-amqplib composer library has greatly been extended.

• The timeline now includes spans for the connection establishment and opening a new channel.
• The publish command now includes annotations for the channel ID and improves reliability for the existing annotations for routing key and exchange name.
• For the amqplib composer library, time spent communicating with the AMQP service will now be tracked more accurately within the “Queue” layer.

Select Organization shown after Log-In

For users with access to multiple organizations, any one organization can now be marked as default by clicking on the star icon and will then be visible immediately after logging in.

For our first Release in 2025, we have cooked up more precise performance insights for you and can now, with Automatic Bottleneck Detection, serve you bottlenecks on a silver platter including recipes on how to fix them. Work on several improvements, like Native Worker Support in the PHP Extension, has kept us busy over the winter. A series of instrumentation improvements has chased away the winter blues and is now making way for a spring full of user-friendliness. We also present you with improvements to the Layer Monitoring and a new Notification Log. As part of the spring-cleaning, we renamed the traces that are compared with each other from Base/Target to Before/After. And that’s by no means all there is to report — dive head first in our Release and enjoy!

Summary:

• Automatic Bottleneck Detection
• Native Worker Support in PHP Extension
• Layer Improvements
• Notification Log
• session_write_close() in Timeline
• Trace Comparison: Base/Target is now Before/After
• Show muted errors in the UI
• Keep User-Agent for crawlers in trace metadata
• Instrumentation improvements

Automatic Bottleneck Detection

A profiling trace in Tideways has a lot of information across Timeline and Callgraph data, and finding bottlenecks usually means diving deep into this data. In the current Release, we introduce a more comprehensive automatic bottleneck detection that is based on the data from traces that we already collect. Instead of having to dig out the bottleneck from the profiling data yourself, if it’s a known problem, we can now show you both the bottleneck AND a solution recipe. Our goal is helping you accelerate bottleneck detection and troubleshooting.

With this foundation, we plan to add automated detection for even more bottlenecks specific to certain frameworks, such as Shopware, Symfony, or Magento. This customization will bring clarity more quickly, as it expedites the process of performance optimization by saving you the time-intensive search for solutions yourself.

So far, detected bottlenecks were displayed only in ‘Traces’ listed in the ‘Bottlenecks’ tab. Now, the bottlenecks will not only be way more detailed; they will also be aggregated to the service level and shown in ‘Observations’. You will get a complete overview in the observations tab and don’t need to sift through individual traces anymore.

Our new bottlenecks can also leverage Callgraph traces. So if you collect Callgraphs regularly, we will be able to gain even more insights into where your system is slowed down. Whilst we are expanding this feature, we incorporate everything we know about PHP performance into bottlenecks.

For now, we have added automatic detection for these new bottlenecks:

• Not using Composer Autoload Optimizations
• Using Symfony’s trigger_deprecation excessively
• Using Shopware’s CartPersister API incorrectly for a huge performance hit
• Blocking page views by using the Facebook Graph API to track Events 

• Documentation: Detect Bottlenecks in Traces
• Documentation: Observations with Bottlenecks

Native Worker Support in PHP Extension

Tideways now automatically detects transaction names for individual tasks executing within worker queues of Symfony, Laravel, Shopware 6, Magento, and WoltLab Suite.

In this Shopware 6 demo application, you can see the worker tasks individually monitored.

Native support for workers improves observability for requests that dynamically perform multiple independent (background) tasks with differing performance profiles.

Previously, Tideways would only detect the execution of a single long-running request, with the collected data and timeline showing the actions of all executed tasks. By automatically detecting the individual tasks and creating separate transactions, Tideways now can clearly attribute individual actions (e.g., SQL queries or HTTP calls) to the specific task, measure the failure rate of individual tasks and point out bottlenecks on a per-task basis. This also enables setting tracepoints on these individual tasks. 

Besides the supported worker queues listed above, we also plan to add more generic support and other frameworks in the future.

• Documentation: Instrument CLI Scripts

Layer Improvements

Additional Layers

While Tideways can already account for much of the time in a request when looking at our performance chart, there is still more to cover. With the following new layers, we can now provide an even more fine-grained summary of where the time is spent processing a request. 

As a result, there is less ‘Unaccounted Wait’ because more time spent waiting can be accounted for; that means more time is assigned to actionable layers. 

The layers are displayed in the averages chart in the performance section and in each trace (see layer report):

New Layer: Waiting for CPU

One of the Additional Layers is ‘Waiting for CPU’. It indicates the time spent waiting for the operating system’s scheduler to free up a CPU core to continue processing the request. It provides an indication that particular requests are experiencing delays in processing that are not necessarily caused by the request itself, but insufficient hardware resources or other processes, such as a database running on the same server, performing computationally expensive processing.

• Changelog: New Layer “Waiting for CPU” improves on “Unaccounted Wait”
• Documentation: What do this Metrics and Numbers mean?

Layer Report: a high-level breakdown of your traces

The first thing you see when you open a trace now is a complete, detailed layer report, a breakdown of all the layers that contributed to the total time of that trace.

Improved Layer Collection

As part of the improvement of the layer functionality, we did not just add additional layers and improved the UI, we also cleaned up the technical basis that collects the layer information within the Tideways extension. 

As a result, the collected data is more precise. For example, async HTTP requests using CurlMultiHandle now measure the time that is spent processing the retrieved data. 

Previously, the entire time from sending the request until the full response is received was measured, which would consider the sum of the runtime of parallel requests, exceeding the actual time spent blocking. 

Notification Log

We added a new ‘Notification Log’ for Errors/Exceptions, Incidents, and Releases. For each of these events, users can now view the date and time of the notifications and through which channel, e.g. Slack or email, they were notified.

session_write_close() in Timeline

Tideways will now indicate with a timeline marker when session_write_close() is used, indicating the time the session is unlocked. This can help other requests to go on without further ado.

When using PHP’s integrated session functionality, sessions are automatically locked for concurrent access while they are in use by a request to prevent race conditions. As a result, requests using the same session are blocked until previous requests finish. When no additional modifications to the session data need to be made, for example in read-only requests, the session_write_close() function can be used to write the updated session data and unlock the session, allowing other requests to proceed without waiting for the request to finish. Similarly to the existing marker for fastcgi_finish_request().

• Detecting Bottlenecks: Blocking Session

Trace Comparison: Base/Target is now Before/After

Previously, we used ‘Base’ and ‘Target’ as names for two traces that were to be compared with each other. This technical reference has now been altered in favor of a temporal perspective. Using ‘Before’ and ‘After’, the naming is now solely based on the chronological order of both traces. ‘Before’ for the older trace and ‘After’ for the newer one. Regardless of the comparison direction, the traces retain their names. It can be Before ⇒ After or After ⇒ Before.

Why do two traces differ in speed? By comparing them, you can detect why. A comparison of two traces can also make optimizations visible. Does the change I initiated make a difference, regarding speed? This question can be answered by making use of the trace comparison.

Show muted errors in the UI

The action ‘Don’t Notify’ for Errors/Exceptions was renamed to ‘Mute’ or ‘Unmute’, and in addition you can now see this in the UI with the crossed-out microphone icon.

Keep User-Agent for crawlers in trace metadata

Since Tideways Release 2024.3, Tideways recognizes requests performed by crawlers and adds a ‘Crawler’ tag. For requests tagged ‘crawler’, the full User-Agent will be available on the root span of a trace, allowing you to take action if an undesired crawler makes excessive requests to expensive routes.

Instrumentation improvements

As always, this Tideways Release includes a number of assorted improvements and bug fixes to the existing instrumentation functionality.

• The experimental MongoDB instrumentation added in Tideways 5.7.0 replaces the old MongoDB instrumentation as of 5.15.0. The new instrumentation is more reliable and provides better insights into the commands used.
• Each MongoDB command span now has peer.host and peer.port annotations, indicating the exact server the command was sent to. The mongo.service annotation on the “connect” span was removed, since the MongoDB client dynamically detects the cluster topology, making this information misleading.
• MongoDB: Logical conjunctions, such as ['field' => ['$gt' => 0, '$lt' => 10]] are now correctly reported in the mongo.filter annotation.
• HTTP requests performed using cURL multi now unconditionally collect a stack trace when calling curl_multi_add_handle(), pointing towards the location where the request is actually initiated, instead of the curl_multi_exec() event loop.
• Collect Shopware DAL spans in the EntityRepository instead of the EntitySearcher to catch more cases.
• A new swdal.criteria.title annotation is available on Shopware DAL spans, containing the result of Criteria::getTitle().
• The instrumentation for colinmollenhour/credis, which amongst others, is used by Magento now supports the tideways.features.redis_keys feature.
• Add the cached tag to pages returned from Magento’s page cache.
• Add automated service detection for WoltLab Suite’s ACP.
• Symfony Messenger transactions now include a span for each message handler.
• Improve Callgraph for Doctrine, by disambiguating calls to UnitOfWork::createEntity(), allowing to measure hydration performance per entity type.
• Instrument Symfony’s ErrorHandler component, allowing to see Exceptions handled by it in Tideways.

You can see these changes listed by PHP extension version on the changelog page.

Get the cake, Tideways is turning ten!

Exactly on this day ten years ago, we lifted the veil on Tideways’ predecessor and thus began our exciting journey that continues to this day.

We would like to celebrate by presenting interesting new features to you.

Summary:

• Differential Flame Graph
• Share Trace Comparison
• Dynamic Instrumentation for Functions from the UI
• Transaction Failure Rate Alerts
• IDE Integrations
• Improved Stacktraces from Third Party Libraries
• FrankenPHP Support
• WoltLab Suite Support

You can also watch a recording of our webinar on the topic, where Benjamin connects all these new features into a small story of improving a Shopware 6 plugin.

Differential Flame Graph

Differential Flame Graphs are a visual representation of a comparison between two sets of profiling data and is a beneficial tool for quickly identifying the root causes of performance problems. To benefit best from the findings, in Tideways they are presented in a comprehensible comparison box which shows the comparison base and the target, a summary and an example span. Unlike before, it’s now possible to see at a glance why a trace has become faster or slower.

It’s useful for instance to check whether a change in the source code, a system update or a configuration change improved performance or brought about a regression. It’s also possible to compare traces from different time periods or of different system states.

The color code depicts the most common way Differential Flame Graphs are presented. Red colors, alert you to an increase in execution time or resource usage. Blue, on the other hand, depicts a decrease. There are different shades of blue and red to depict minor or major decreases and increases. Neutral colors mean that no significant change has occurred.

Our Differential Flame Graph is interactive; you can hover over or click on the different areas to get more specific information.

The high level of detail helps to find an unwanted outlier in time or memory consumption faster.

Changelog: Differential Flame Graph

Share Trace Comparison

The comparison of two traces can now be shared with persons who don’t have a Tideways account or are not members of the respective organization. This is an immensely helpful addition to the existing feature that already allowed the sharing of a single trace.

You can click the share action directly from a trace comparison and share a link to it. That makes investigating performance problems and validating improvements much easier.

When sharing a trace in Slack or in other chat / social media tools, a preview is generated to offer the message receivers a summary:

Changelog: Share Trace Comparison

Dynamic Instrumentation for Functions from the UI

Dynamically instrumented functions are a new feature within Tideways to improve Profiling data and in turn identify performance problems even faster.

Previously, instrumentation was either defined within the Tideways extensions and could be added by changing the code to use the attribute #[WithSpan]. Now you can add instrumentation to your functions by simply clicking the “Dynamically Instrument Function” button from the callgraph interface. 

No changes in your application code or deployment of a new version needed!

Documentation: Instrument Functions from the UI

Changelog: Dynamically Instrument Functions

Transaction Failure Rate Alerts

What failure rate is acceptable for individual transactions? To find out what causes errors in one specific transaction, a failure threshold can be set for each individual transaction. The failure threshold is based on a list of predefined percentages and can be configured via the transaction settings page. 

To that end, you can set up a notification under “Project Settings > Notifications”. You then get notified via Slack or email or other supported integrations when the failure rate for a transaction increases and it needs attention to be resolved. 

For more details on how to configure it view our documentation.

IDE Integrations

You can now use the “Open in IDE” icon in Errors and Callgraphs. This makes it easier to directly switch from Tideways into the code and start fixing a bug or performance problem.

At the moment you can configure this integration for PhpStorm and VSCode. For third party libraries you can also directly jump to the code on GitHub without the need to configure anything.

For more details view our documentation.

PHP Extension:

Improved Stacktraces from Third Party Libraries

For libraries such as Doctrine, Guzzle and Laravel, stacktraces in the Timeline Profiler are now modified to show primarily frames from your code-base and not from the library. Before, due to the limiting of the stackframes size they sometimes included only frames from the library itself and no indication where in the application they occurred. Relevant ones were sometimes cut off. Now, the stacktrace is cut off to show primarily application-code function calls.

In addition we reduced the default duration for a span to keep its stacktrace from 5ms to 3ms and increased the number of stacktraces Tideways keeps per trace across plans.

FrankenPHP Support

Tideways is the first APM solution that fully supports FrankenPHP, including worker mode. Starting from PHP extension 5.8.0, Tideways supports FrankenPHP.

Worker mode only loads your framework once into memory. Subsequently, it sends requests to the same instance of your application and doesn’t spin up a new instance for every new web request. 

That means that one gives up the shared nothing of for example PHP-FPM or even FrankenPHP without worker mode but saves time and optimizes performance. 

For more details on how to use FrankenPHP with Tideways see our changelog entry and our documentation.

WoltLab Suite Support

Tideways now also includes instrumentation of WoltLab Suite out of the box. The Tideways PHP Extension will automatically detect which type of page of your community has been accessed to automatically fill in the transaction name, making the collected data useful without requiring manual changes on your end.

In the 4 months since the last release (2022.4), we have been working on a number of new features and improvements that we are pleased to share with you today as part of our 2023.1 release of Tideways.

In addition to the new features, we also revamped our pricing and plans at the end of March under the umbrella of “Tideways 6”. The main difference is that all plans now include all features and are now limited by transactions as the primary metric.

Summary:

• Monitoring for tagged transactions
• Performance Budgeting with Response Time Targets
• Profiling Spaces
• Trace sharing
• Performance improvements for multi-host projects
• Variable Timeframe in Error Count Chart

Monitoring for tagged transactions

In 2022.3 we added support for cached and uncached tags assigned to traces. As part of the Tideways 6 release, we are extending this feature to monitor tagged transactions individually. You can view the minute-by-minute performance of the transaction as a whole and broken down by any tags assigned.

In addition to the “cached” and “uncached” tags set automatically for Shopware 6 projects or via the markPageCacheHit/markPageCacheMiss APIs, the PHP extension now includes a new Profiler::setTags() function for setting up to 3 tags per request.

More Information:

• Documentation: Performance Segmented by Tags
• Documentation: Tideways\Profiler::setTags()

Performance Budgeting with Response Time Targets

In preparation for supporting performance budgeting, we renamed “Errors” to “Failures” in the previous release. With the addition of Response Time Targets, Tideways can now mark requests as failed if they take longer than a configured response time in milliseconds.
This configuration is available at the service level and, with the new Tideways 6 plans, at the transaction level.

Combined with the existing failure rate notifications, this enables fine-grained performance budgeting and alerting.

More Information:

• Documentation: Configure Response Time Targets

Profiling Spaces

One of the missing pieces in Tideways’ organization, project, and pricing is a space where you can collect profiling data for any PHP script you want to test around, analyze open source code you depend on, or small projects that are not monitored.
With the new Tideways 6 plans, we are introducing Profiling Spaces as a secondary mechanism for grouping profiling data besides projects.

In a Profiling Space, you can only trigger traces via Chrome Extension, CLI or Magic Query parameters.

A limit of profiles per day depending on the selected plan is the main restriction in the use of profiling spaces.

More Information:

• Documentation: Profiling Spaces

Trace sharing

You can now share traces with people outside your organization. Each trace has a Share Trace button that initiates the process. You configure the duration of the sharing and a unique link is generated that requires no authentication to view.

For existing organizations, only administrators can share a trace at this time. You can change which users are allowed to share in the organization’s user settings.

For new organizations created after this release, all users can share traces by default.

More information:

• Documentation: Trace Sharing

Performance improvements for multi-host projects

For projects with a large number of hosts, starting with 5 or more, we have added an additional aggregation step for the monitoring data, which significantly improves the performance of the UI for the service and transaction monitoring screens. When looking at a 24-hour time frame of the project this often shaves several seconds off the response time.

Variable Timeframe in Error Count Chart

In addition to showing hourly error counts for the last 3 days, the Error Details screen now has the option to show minute-by-minute data for the last 2 hours, or longer time frames of 5, 14, or 30 days (depending on the retention days of the project license).

This post contains a comprehensive list of all the features that we worked on and deployed over the last 3 months, all included in this 2022.4 release.

PHP Extension

We have released PHP extension version 5.5.12 with the following changes:

PHP 8.2 Support

The end of the year brings another new PHP version 8.2, due to be released on 7th December 2022. Tideways is already fully compatible with PHP 8.2.

This is the first PHP release that includes work sponsored by the PHP Foundation. Tideways is a major sponsor of the foundation and we are very proud to support the PHP language by funding developers to work on it. In fact we have increased our support to $15.000 this year.

One notable change in PHP 8.2 that affects Tideways is the improvement of the Observer API to include internal functions, which should further reduce the overhead of Tideways in Callgraph mode.

Monitoring

Rename “Errors “to “Failures”

The “Errors “metric used in Tideways’s monitoring, weekly report, and history components is now named “Failures”.

This is done primarily to avoid confusion with the Errors/Exception Tracking due to slightly different semantics.

“Failures “in the monitoring component can either be:

• Requests aborted by Exceptions or Fatal Errors
• Requests sending an HTTP status code of 500 or above (without exception)

Default Service of new projects is now “app”

Previously the first and default service of a new project was called “web “.

We changed this default to “app “for all new projects created since October. Existing projects will keep “web “as their default service if in use.

This rename is due to a change in the service feature we are currently preparing and to increase clarity for users.

Splunk OnCall (VictorOps) support for alerting

Customers can now integrate with Splunk OnCall (formerly VictorOps) to send notifications.

Documentation: Splunk OnCall

Profiler

Filter Traces by specific Day

In addition to selecting traces by pre-defined ranges such as “Last Day “or “Last 7 days “, users can now filter traces by a specific day.

Account Management

Two-Factor Authentication

Tideways now supports adding Two-Factor Authentication to user accounts. In addition, organization admins can require all members of an organization to use Two-Factor authentication for access.
Documentation: Two-Factor Authentication

Single Sign On with Azure Active Directory

Tideways now supports Azure Active Directory SSO. Contact [email protected] to get access to this feature.
Documentation: Azure AD SSO

Improve Settings Visibility for all members of an organization

The current settings of an organization and its projects are now visible to regular and privileged users. This helps users to understand how Tideways is configured so that they know when and how to ask an admin for changes.

In this post we post a comprehensive list of all the features that we have worked on and deployed over the last 3 months, all included in this 2022.3 release.

Monitoring

Page Cache Hit Rate for Services and Transactions

Monitoring for services and transactions now supports calculating the hit rate for PHP-based page caches. For example, if you have a full page cache storing the HTML on the filesystem, Redis or any system, then using the Tideways Profiler API, you can mark a response as cache hit or miss. The hit rate is then calculated on the service and transaction level automatically:

For Shopware 6 applications, automatic instrumentation into the Page Cache API is provided so that no code changes are necessary to calculate the cache hit rate.

In addition to the monitoring, there is also a new observation for the page cache hit rate, letting you know if it’s not doing it’s job. You can find more information in the Page Cache Hit Rate observation documentation.

One more for Shopware 6, there are extras; the product and category details pages have their own page cache hit rate observations.

• Feature Documentation: Page Cache Hit Rates
• API Reference: Tideways\Profiler::markPageCacheHit and Tideways\Profiler::markPageCacheMiss
• Observation Reference: Page Cache Hit Rate is low

Change the Default Environment Name

The environment support in Tideways previously had the hardcoded default environment “production” that received the primary load of traces. It is now possible to change the default environment to something other than “production”. See the documentation on how environments work and how to configure them if you want to make use of this change.

Profiler

Tagging Traces as Cached or Uncached

Using the page cache hit rate API introduced in the previous section, traces that are either cached or uncached are tagged as such in the trace list and details now:

There is a new filter “Tags” so that you can select “Cached” or “Uncached”. We are planning to add other tags and an API to add custom tags.

Callgraph Profiler: preg API regular expression profiling

With PHP Extension 5.5.8, the Callgraph Profiler includes support for argument capturing for the PHP functions preg_match, preg_match_all, preg_replace and preg_split. These functions are often performance bottlenecks due to inefficiencies in the patterns combined with their excessive use. By capturing the first 30 characters of all patterns, we group the functions in the callgraph, making it much easier to identify which regular expressions are performance bottlenecks and which are not.

Timeline Profiler: Shopware 6 Data Access Layer

The Timeline Profiler now includes timespans for the Shopware 6 Data Access Layer, similar to our instrumentation of Doctrine or Propel ORMs. For product and category DAL this even includes the Criteria query.

Exception Tracking

Resolve All Errors

We added a “Resolve All” button in the exception tracking list that allows resolving all open errors. This action only applies to the currently selected environment, service and optionally transaction(s).

This can be helpful when you want to reset the notifications and occurrences without having to create a release event.

Exceptions across Environments

Exceptions will now be tracked separately by environment starting October 1st 2022. The change is dated since its a backwards incompatible break from the previous behavior. You can opt into the feature using the “Beta Features” section of Tideways.

This change to exceptions by environment includes occurrences, stacktraces and notifications. When you are using different environments, then enabling this feature will initially trigger new notifications for all errors in non-production environments.

When triggering a release for an environment and service, only errors of these will get reset and notify again, according to your notification filter settings.

Chrome Extension

Building on the changes in the 2022.2 release, we have improved the Chrome Extension further:

• Show that profiling is still in progress when triggering traces for the next 15 or 60 seconds. This provides better feedback about the current state of a profiling session and prevents the trigger buttons from being clicked multiple times and causing confusion.
• Improve rendering of projects and previously collected traces in the Chrome extension popup screen.

Your chrome extension was auto-updated to version 1.5.2 a few weeks ago, which already includes these changes.

Commandline Interface (CLI)

We have relased the tideways CLI tool as version 1.0.0 now, it required very little changes and bugfixes in the past years, so that a 0-point version number does not communicate the stability of it well.

One user facing changes is included in this release:

• Bugfix: Always query backend for traces, even when executed PHP command failed with non-zero exit code. This is important when running for example phpunit, psalm or php-stan under Tideways profiling, while they throw errors.

In this new release, there are changes to many different parts of the Tideways stack. This includes new releases to the PHP extension (5.5.2), daemon (1.7.26, 1.7.28), CLI (0.4.6), and Chrome Web Extension (1.5.1).

Add Generic Markers to Charts

In addition to the existing Release and Deployment events, it is now possible to add generic markers to the performance charts to indicate an event for example “Beginning of E-Mail Marketing Campaign”, or “OpCache Configuration Change” or “MySQL Upgrade”. Performance before and after the marker event is comparable to allow investigation of its effects on the application.

You can create markers through a new button called “Add Marker” that is now present on the Application/Service performance screens and for selected snapshots. In addition, markers can be created through the event REST API or the CLI.

Smarter Long SQL Statement Truncation

SELECT statements longer than 4000 characters are now using a smart parser in the PHP extension to keep all parts beginning with the FROM clause instead of the column list during truncation.

Before the new version 5.5 release (May 2022) of the PHP extension, very long SQL statements were truncated to 4000 characters to reduce the payloads sent from PHP extension to the daemon over socket or TCP/IP. This could produce truncated SELECT statements that did not include the FROM, JOIN or WHERE parts because the column list was already very large, for example including a subselect or entities with many fields in Doctrine ORM.

Chrome Extension shows triggered traces

The Tideways Chrome extension will now store links to the resulting traces when using the “Take Profile” feature. This will allow you to keep going back to the last ten recently generated traces by clicking on the Tideways extension icon inside Chrome.

Before this change, it was necessary to click on the traces immediately in the popup to avoid losing the links.

Navigate between Referenced Traces

When you trigger traces through the Chrome extension, CLI or tracepoints, all traces include a shared reference UUID generated at the time and stored in our database. The trace view screen now has a new tab called “References”, which shows all referenced traces.

New and Updated Instrumentation in PHP Extension

The version 5.5.2 release of the PHP extension includes a few other notable changes:

• The transaction name of cached requests in Shopware 6 is now correctly detected. Previously the fallback transaction name “public/index.php” was used.
• We improved the Symfony instrumentation for event listeners and transaction name detection.
• Improved Laravel exception tracking support
• A bug was fixed for curl multi instrumentation incorrectly batching spans together, leading to information inaccuracy in the Profiler.

Other notable changes

There are a few other notable changes:

• The Performance Metrics REST API was improved to include median and all downstream layeImproved The Performance Metrics REST API to include median and all downstream layers in the response.
• The weekly report and export charts now show the requests as a second y-axis.
• Updated the CLI tool to allow sending events for any environment via the –environment flag. Previously the environment was hardcoded to “production”.
• SQL Connect operations are now identified as “CONNECT” in the Timeline Profiler instead of “OTHER”.