Services
The services feature allows you to group transactions into different sets that belong together and get aggregated together in their own chart and overall response time.
When your project is a combination of multiple services combined with CLI scripts or workers running in different contexts, then having just one aggregated chart with just one response time can distort your view of the real picture. The response times, request numbers and failure rates are aggregated by comparing apples with oranges.
Services can be switched from the top level navigation of any project. Depending on the number ofservices in a project you see an expanded selector or a dropdown:
How Services Work
Services allow a project to distinguish between different types of users. Depending on the purpose of your project, this distinction may be helpful _or it may be critical. That’s because only if the group of users is uniform (e.g. a shop’s end users vs. its backend administrators) is aggregated data is meaningful.
Why is this? When a project is made up of multiple services (such as micro-services and different user types) combined with CLI scripts and workers running in different contexts, a single aggregated graph can distort the perception of how the project is working. This is because the needs and timing of regular users are very different from backend, administration type users.
For example, if the performance of backend transactions is slower than for regular users, this may be perfectly acceptable. However, for regular users, slow transaction response times can mean the difference between a successful purchase and a shopping basket abandoned for another online store.
By aggregating them, it would be impossible to distinguish one from the other. You couldn’t tell if the frontend response times were higher than they should be, or if the backend response times were unnaturally low.
By using multiple services, the information stored becomes much more meaningful.
CLI Subservices
Fundamentally Tideways understands services as "web-based", responding to requests from browsers or API clients.
Commandline based programs such as cronjobs, one-time scripts or background processes complement these web-based services, but their runtime performance is usually very different and should not be aggregate and viewed alongside with the web-based performance data.
This is why all commanline based PHP scripts are grouped into a dedicated "CLI" sub-service, attached to their parent service by name. This service is denoted with a ":cli" suffix, for example "app:cli".
Think of this as two different contexts of the same service, "web" and "cli" context.
| A service that reports for both "web" and "cli" context still counts as one in relation to the service-limit. For example with the services "app", "app:cli" and "admin" count as 2 services. |