-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement nginx's $request_time logging parameter #3547
Comments
This makes sense to me at a high level. Could you summarize the network issue and how you ended up debugging it? |
The network issue was that the clients connected to graphql-engine (deployed on k8s with istio) were noticing that the requests take a long time to finish(1-2 seconds). However in the logs of graphql-engine, the execution times were in the order of few milliseconds. The network connection between graphql-engine and the client was the issue. If |
By adding logging on the clients and tracing those requests in graphql-engine (through a session variable x-hasura-trace-id). |
Add a new 'query_io_time' to the logging record. We also use withTiming to get proper monotonic clock for 'query_execution_time' as well.
Add a new 'query_io_time' to the logging record. We also use 'withElapsedTime' to get proper monotonic clock for 'query_execution_time' as well.
Add a new 'query_io_time' to the logging record. We also use 'withElapsedTime' to get proper monotonic clock for 'query_execution_time' as well.
Add a new 'request_read_time' to the logging record. We also use 'withElapsedTime' to get proper monotonic clock for 'query_execution_time' as well.
Add a new 'request_read_time' to the logging record. We also use 'withElapsedTime' to get proper monotonic clock for 'query_execution_time' as well.
Add a new 'request_read_time' to the logging record. We also use 'withElapsedTime' to get proper monotonic clock for 'query_execution_time' as well.
@0x777 Why is this reopened? |
@lexi-lambda Because @jberryman added the time taken to read the request body, but |
Got it, thank you! Maybe we need to add it at the WAI level, then? |
@0x777 IIUC
While I was working on Server Metrics issue - I noticed that in our Referencing from the code:
(ioWaitTime, reqBody) <- withElapsedTime $ liftIO $ Wai.strictRequestBody req
(serviceTime, (result, q)) <- withElapsedTime $ case apiHandler of
AHGet handler -> do
res <- lift $ runHandler handler
return (res, Nothing)
AHPost handler -> do
parsedReqE <- runExceptT $ parseBody reqBody
parsedReq <- onLeft parsedReqE (logErrorAndResp (Just userInfo) requestId req (reqBody, Nothing) includeInternal headers . qErrModifier)
res <- lift $ runHandler $ handler parsedReq
return (res, Just parsedReq)
-- | Time an IO action, returning the time with microsecond precision. The
-- result of the input action will be evaluated to WHNF.
--
-- The result 'DiffTime' is guarenteed to be >= 0.
withElapsedTime :: MonadIO m => m a -> m (DiffTime, a) If I understand all of the above correctly, will the following be a proper definition for
where
If the definition of |
@0x777 Just wanted to check in on this - I'm just an invested user, wondering if there is anything I could do to contribute to push this along? It seems like the data is there, just not exposed in the logging output at this time |
Currently, we only log the execution time for a given request. It would be nice to measure the time from 'the arrival of first byte of the request' to the 'last byte sent as response'. This can help people debug network issues easily.
From nginx's docs:
The text was updated successfully, but these errors were encountered: