Transactions
Tideways assigns a transaction name to each request, a name that represents the operation, endpoint, controller, page type or script being executed.
Ideally, each block of code that performs a specific function in your project has its own unique transaction name, so that performance can be maintained across many block of code can be aggregated and compared over time. This includes the number of dedicated requests, response times and failure rates per transaction.
Examples of transactions are:
-
The product category, product detail and search listing pages in an E-Commerce store
-
The document page and search results pages in a Content Management System
-
The login, registration, forgot password pages in a SaaS or business application
Automatic Transaction Naming
By default, each transaction is automatically given a name consisting of the
last two parts of SCRIPT_FILENAME
(for example web/index.php
) as the
transaction name.
If you are using a framework supported by Tideways, then the transaction name
will be the controller class / action method that is being executed (for
example App\Controller\UserController::viewAction
).
See the list of supported frameworks.
Programmatic Transaction Naming
If you are using a currently unsupported MVC framework, then a programmatic assignment of the transaction names will provide much more insight than the default script name based naming, that Tideways relies on. See docs on the programmatic Transaction API to manually set transaction names in your application code.
Transaction Limits and Limited Visibility
The number of transactions is restricted based on the project license and upgrades. It is therefore recommended that you set transaction names based on blocks of code that are countable and known, rather than based on URLs or database entries which could potentially be infinite.
Transaction Visibility can be "Full", "Limited" or "Ignored". Each state has its own limits per project that are shown on the Project License page.
Once the limit of "Full" visibility transactions is reached, further transactions are still created but have their visibility set to "Limited" instead of "Full".
A transaction with the same name will be counted as multiple transactions if it is used more than one environment or service. Transactions in environments with "Limited" visibility always have "Limited" visibility on their own by default. They can be changed to "Full" visibility manually.
"Limited" visibility transactions are stored only with their request count, average response time and failure rate. Traces of a limited transaction are deprioritized during sampling and are only kept if not enough traces of full transactions are collected.
After the "limited" visibility transaction limit is reached all additional transactions are created with the visibility ignored until another limit is reached and they are grouped into a single "catch all" transaction named "Uncategorized".
Ignored transactions do not count towards the service monitoring data, collect no own monitoring data, no traces and no exception data.
You can change the visilibity of each transaction on different screens:
-
On the transactions detail page in the right hand side dropdown menu.
-
On the project "transaction settings" page
-
On the list of tagged transactions for a parent transaction
In addition a daily cleanup job performs the following tasks:
-
Delete all transactions that have not collected requests for longer than the history retention.
-
Only if the limit is reached, mark all transactions with limited visibility that have not collected requests for over 35 days.
-
only if the limit is reached, mark all transactions with ilimited visibility that have collected only a single request and that was over 14 days ago.
-
Mark all transactions as ignored that belong to an inactive service or environment.
-
Only if the limit is still reached, Ignore all transactions with limited visibility that have not collected requests for over 45 days.
The following tables describe the transaction limits and behavior in different licenses and plans:
Current Plans |
Starter |
Basic |
Standard |
Pro |
Transaction Details |
Yes |
Yes |
Yes |
Yes |
With Downstream Layers |
Yes |
Yes |
Yes |
Yes |
With Tagged Transactions |
No |
Yes |
Yes |
Yes |
With Response Time Targets |
No |
Yes |
Yes |
Yes |
Full Visibility Transactions |
20 |
250 |
500 |
1000 |
Limited Visibility Transactions |
480 |
750 |
1000 |
2000 |
Transactions (Full) in Increased Limited Add-On |
x |
125 |
250 |
500 |
When Limit is Reached |
Ignore |
Ignore |
Ignore |
Ignore |
Trace Sampling for Full Visibility |
Least Recently |
Least Recently |
Least Recently |
Least Recently |
Trace Sampling for Limited Visibility |
Slowest |
Slowest |
Slowest |
Slowest |
Full Visibility for Multiple Environments |
Yes |
Yes |
Yes |
Yes |
Tideways 5 (Legacy) |
Flex/Request |
Basic |
Standard |
Pro |
Transaction Details |
No |
No |
Yes |
Yes |
With Downstream Layers |
No |
No |
No |
Yes |
With Tagged Transactions |
No |
No |
No |
Yes |
Full Visibility Transactions |
0 |
0 |
1000 |
5000 |
Limited Visibility Transactions |
500 |
750 |
500 |
1000 |
When Limit is Reached |
Uncategorized |
Uncategorized |
Uncategorized |
Uncategorized |
Trace Sampling for Full Visibility |
No |
No |
Least Recently |
Least Recently |
Trace Sampling for Limited Visibility |
Least Recently |
Least Recently |
Least Recently |
Least Recently |
Full Visibility for Multiple Environments |
No |
No |
No |
Yes |
Failure Thresholds
Failure Threshold are currently in Beta and need to be activated from the Beta Features settings in your organization. |
Every transaction has a failure threshold setting that affects when the transaction failure rate notification is triggered. By default a transaction has no failure threshold configured and you can change it to become:
-
Immediately fail when any request of this transaction fails
-
Fail when at least 1% of all requests fail
-
Fail when at least 5% of all requests fail
-
Fail when at least 10% of all requests fail
-
Fail when at least 25% of all requests fail
-
Fail when at least 50% of all requests fail
For simplicity and to enable bulk editing of this setting for many transactions, it is not possible to set a custom value.
To change the failure threshold of a transaction you can either open the "Edit" configuration dialog of the transaction individually, or use the bulk action to change the failure threshold of several transactions at the same time.
Deleting Transactions
You can delete individual transactions from their actions menu in the transaction settings screen.
This action helps to manually free up the transaction limit if you are at the maximum and want to replace old transactions forcefully and do not want to wait on the cleanup job to free up space.
Be aware that removing a transaction that is still active will only lead to the transaction being created again.
Configuring Human Readable Names
After you have started using transaction names based on framework or manual support, you can go one step further and set a human readable name for all transactions or just for the ones which you care about the most.
Doing so improves the utility of Tideways, because it frees you from having to
know what page each listed controller/action
is responsible for — especially
for the non-technical users in the weekly report. For example in the
transaction list:
Or in the transaction detail page:
To configure a human-readable transaction name:
-
Go to
-
Click the configure transaction (pencil) icon, at the far right-hand side of the transaction which you want to name
Figure 1. View the list of transactions under the project’s settings -
Specify a name for the transaction in the Name field, and then click Save
Figure 2. Setting a transaction’s name
Following this, you will then see the configured human-readable name, in the Name column, next to the transaction in the transactions list.
Delete All Transactions
If you want to start over with a new transaction naming schema, you can go to "Project Settings" > "General Settings" and perform the "Delete all Transactions" action.