You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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:
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)
The text was updated successfully, but these errors were encountered: