1. Tideways Overview

What is Tideways? Good question. To help answer that question, in this video, you’re going to get a 30,000 ft view of what Tideways is.

With a product as sophisticated as Tideways, that’s not an easy thing to do - at least not quickly. So, we’re going to focus on its three essential concepts; those being:


Let’s start with monitoring. Often referred to as Application Performance Monitoring or Application Performance Management (APM for short), monitoring is

The monitoring and management of performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service.
— Application performance management

So, why would you use monitoring in your application? The monitoring section is where you get a broad overview of your application, including:

  • How long a spike took

  • Maximum memory usage

  • Response rate averages (such as SQL queries and file I/O)

  • The total number of requests

  • What you need to investigate; and

  • Where you see when outliers happen

In short, you’re able to gauge the health of your application rapidly and know if and where something is going wrong.

application performance overview

The Application Performance Overview, which you can see in the screenshot above, shows your application’s performance, with response times measured in 95% percentiles. Hovering over each minute, you can see the exact response-time and the number of requests that were measured.

Blue bars represent the response time with the y-axis on the left of the chart, red bars represent the number of errors and the dashed grey line the number of requests with the y-axis on the right side of the chart. The main performance screen also shows the aggregated 95% response time, number of requests, and error-rate of the currently selected time period.

Below the main response time chart is a smaller chart that shows downstream layer performance from SQL, HTTP, Redis, Memcache, MongoDB, and other supported databases. Hover over the graph with the mouse, and you see the exact response times and request count, errors, and averages for the selected time.

individual layer response times and percentiles

The graph with response times is the entry point to every application. You can select different periods to look at with the time-selector. By default, it shows the last 60 minutes; other durations are 3 hours, 12 hours, 24 hours. However, you can switch to the history view to view the previous 1 day, 7 days (one week), or one month.

To view the performance at different points in time, you can select different periods via drag-and-drop in the time explorer at the top of the screen, or switch between services (like CLI, Web, Admin or anything you want to group by) and environments (like production, staging, testing).

Special events such as new exceptions, new releases, or alert triggers are displayed as little flags in the application performance chart. You can click them to get more details about what was happening in your application.


Next, what is profiling? To again quote Wikipedia:

Profiling ("program profiling", "software profiling") is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization.
— Profiling (computer programming)

Sounds intense, right? So why should we profile our applications and scripts? Well, often, though not always, when something goes wrong, or our applications aren’t performing as we expect that they should, we dive right in and attempt to guess where their performance bottlenecks are.

We use intuition and educated guesses. While doing so can work, it’s not the most efficient approach. Intuition and educated guesses aren’t based on facts.

That’s why we should profile our applications so that we know for a fact what our applications are doing. Then, we can base our choices about what to change and where based on clear and unbiased facts.

For example, here’s a little of what profiling can tell us:

  • By how much did a function increase peak PHP memory usage during its execution?

  • How long did a specific SQL database query or HTTP request take?

  • How many times was each method called?

  • What path did a request take through an application (from the first to the last function)?

  • What was the average execution time of each method?

  • What was the maximum execution time of each method?

Tideways supports two profiler types, these are:

The Timeline / Tracing Profiler

This profiler collects information about a range of operations performed by your application, such as SQL statements, framework controller calls, and rendering of templates.

The Callgraph Profiler

This profiler provides a visual representation of an application’s callgraph, which is more detailed than the timeline profiler.

We’re not going into further detail about them in this video, as I don’t want to dive too deep too soon. But, we cover the Timeline profiler in video four and the Callgraph profiler in video 5.

Profiler Summary

By drilling down into a profiler’s results, you can often be pleasantly surprised — though more likely shocked to find that your application is executing code paths and classes that you never expected. However, based on the information which the profilers report, you and your team can then begin to understand better what your application is doing and perform informed refactorings to change it, as and where required.

Exception Tracking

exception tracking

Finally, let’s look at exception tracking. Exception tracking tracks the low-level details for failed requests with errors and exceptions, including stack traces. Tideways automatically detects PHP fatal errors and exceptions and aggregates them. The available error details include the message, stack trace, and context information to help you fix your customers' bugs as fast as possible.

Exception tracking provides several benefits, but two are essential; these are:

  1. Knowing about errors as soon as users encounter them. This allows you to respond quickly and proactively rather than after users contact you in when they’re feeling frustrated.

  2. They avoid the "one email per error" flooding problem. While it’s great to know about errors, the last thing that you want is to be overwhelmed by notifications about them, preventing you from doing meaningful work.

In Summary

And that’s a rapid overview of what Tideways is, focusing on its three core concepts: profiling, monitoring, and exception tracking. By using these three tools in combination, you can quickly go from a high-level right down to the low-level getting a thorough understanding of where the problems in your application lie.

Still need help? Email [email protected]