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
Tank currently supports two blocking httpClients (apache httpclient 3.1 and 4.5). These httpclients make a request and wait for the response and parse the response before continuing on the the next call.
Issue
The existing state fails to produce conistent TPS, as the server endpoint changes performance. Faster RT equals higher TPS, and vise-versa. A completely non-blocking solution would not work because certain calls rely on the response data from a previous call.
Solution Stage 1
Include a Non-blocking Async http client like netty that would execute requests with a non-blocking futures form. This is a backward compatible state.
Solution Stage 2
Add an extra boolean to the request data_model, xml, gui, etc. So that requests can be marked async or not. The ultimate outcome would allow may flow events to be blocking, while beaconing/uilogger calls would be sent off and processes the responses when ever, without blocking the primary flow.
The text was updated successfully, but these errors were encountered:
Existing State
Tank currently supports two blocking httpClients (apache httpclient 3.1 and 4.5). These httpclients make a request and wait for the response and parse the response before continuing on the the next call.
Issue
The existing state fails to produce conistent TPS, as the server endpoint changes performance. Faster RT equals higher TPS, and vise-versa. A completely non-blocking solution would not work because certain calls rely on the response data from a previous call.
Solution Stage 1
Include a Non-blocking Async http client like netty that would execute requests with a non-blocking futures form. This is a backward compatible state.
Solution Stage 2
Add an extra boolean to the request data_model, xml, gui, etc. So that requests can be marked async or not. The ultimate outcome would allow may flow events to be blocking, while beaconing/uilogger calls would be sent off and processes the responses when ever, without blocking the primary flow.
The text was updated successfully, but these errors were encountered: