Performance

Performance shows the slow spots of your apps. It groups them like errors: the same slowness repeated is one row, with its timings. The data comes from the SDKs that can send it.

What you find in the list

Each row has a Category:

• Slow query: a database request that takes too long. Queries are grouped by shape, not by the values they contain: WHERE id = 4 and WHERE id = 9 are the same group.
• Slow method: a part of the program you measure yourself, grouped by the name you give it.
• Performance issue: a slowdown the monitoring detects by itself while the app works.

For each group you see how many times it happened, the average duration, the longest one and the Total time spent. The few samples mark means fewer than 20 cases: the average is not reliable yet.

Problems detected automatically

The first four come from server applications, the last three from mobile apps. You only see the ones your programs can send. To filter them use Problem type.

Tell if something is getting worse

Open a group. The first chart is Duration over time: each bar is the worst case in that slice of time (p95, the time only 5% of cases exceed). Hovering shows the typical case too (p50). The second chart, Occurrences over time, counts how many times it happened. They are two different charts because something can happen just as often and meanwhile take twice as long.

Above the chart is the Average in the period and how much it changed against the previous period of the same length: for example the last 24 hours against the 24 before. If there was no earlier data, the page says so instead of making up a change.

Below are the occurrences. Select one to see the query, with values replaced by ?, and the Logs & errors of this request.

The actual values used by a query (the Parameters) are not collected by default. The page shows the line to add where you connect the app to collect them. They may contain personal data: they are saved as they are and anyone who sees the page sees them. Columns like passwords and tokens stay hidden anyway.

Change when something counts as slow

Timings are colored: green below 150 ms, amber in between, red from 500 ms up. Each project can have its own thresholds:

1. Open the project, then Settings.
2. In the When an operation counts as slow section write the milliseconds for green and for red.
3. Leave them empty to use the default values.

Sort and open a ticket

Like errors, each group is Unresolved, Resolved or Ignored. To change the status, select one or more groups in the list and use Resolve, Ignore or Reopen in the bar that appears. Unlike errors, a resolved group does not reopen by itself.

To turn a slowdown into work, open it and press Promote to ticket: a ticket linked to the group is created.

cyi metrics list --project acme-api
cyi metrics promote <id> --project acme-api

Sorting and promoting need the "Promote slow query/method to ticket" permission.

Get an alert

The Performance issue alert rule fires when a problem detected automatically arrives. Slow queries and slow methods do not create alerts. The same group does not trigger more than one alert per hour.

In the rule you can set the Duration threshold: the alert fires only if the case lasts at least that many milliseconds. It does not apply to High query count, Repeated HTTP and Rebuild storm, which are measured by counting, not by duration. How to create rules: Alerts.

How long data is kept

Single cases are kept for 30 days; the total count stays forever. The duration chart only looks back as far as retention. To change it: project, Settings, Performance retention (days).