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
When we tested in a 144-node cluster, the overall experiment from the client to scylla exceeded 1s, but the delay from scylla itself did not exceed 1s. I am not sure where this problem occurs, and the client gave an error message of connect timeout. Preliminary It was judged that the connection failed twice and the third time was successful, so the overall delay was more than 2s. However, when I adjusted the listen_backlog parameter in seastar from 100 to 150, the p99.9 delay was reduced, and no more than 2s occurred. Latency, can you analyze the reason for this high latency, and what is its relationship with the listen_backlog parameter?
The text was updated successfully, but these errors were encountered:
When we tested in a 144-node cluster, the overall experiment from the client to scylla exceeded 1s, but the delay from scylla itself did not exceed 1s. I am not sure where this problem occurs, and the client gave an error message of connect timeout. Preliminary It was judged that the connection failed twice and the third time was successful, so the overall delay was more than 2s. However, when I adjusted the listen_backlog parameter in seastar from 100 to 150, the p99.9 delay was reduced, and no more than 2s occurred. Latency, can you analyze the reason for this high latency, and what is its relationship with the listen_backlog parameter?
The text was updated successfully, but these errors were encountered: