Skip to content

Metrics that matters #14

@danish-cashify

Description

@danish-cashify

How about we add some metrics that matters?
Often people wanna know which component took most of the time when a request gets stalled or if a request is taking more time:

  • in development phase of a listing api
  • in maintenance phase of a listing api
    Speaking in terms of this package as everything is broken down into components we can decide to log time component wise.

client request passes through all the components and we can log the difference between entry & exit time.

The major impact will come at pagination level when data actually gets allocated into the memory as the listing query hits sql server at this stage. Other than this in filters we hit sql server for validation purposes which is kinda depend on the stuff or params that we are receiving.

standard unit of time - milliseconds

A standard chart could like something like this

Request enters at: 2023-12-05 13:09:00(1234567890)(unix time)
|
|Prepare Query: 0.1 ms
|
___ using xyz strategy listing query received in 0.03ms
|____ query filters applied in 0.06ms (this should expand in case of multiple filters)
|____ query sorting applied in 0.01ms (this should expand in case of multiple sort)
|Paginator: 5ms
|
___ query hits sql at: 2023-12-05 13:09:01(1234567890)(unix time)
|____ sql response returned in 5ms
Request exist at: 2023-12-05 13:09:06(1234567890)(unix time)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions