FAQ
I've discovered that setting a ReadTimeout on an http.Server and serving
many keep-alive requests on it results in the connection being reset by the
server after the read timeout expires.

To work around this, I am disabling keep-alives in the server by setting a
"Connection: close" header.

However, this makes it difficult to benchmark locally because of port
exhaustion.

This behavior seems surprising to me--I would have expected the read
timeout to reset after each request. I also don't see a way to determine
how many requests have been served over a single connection, nor how long
until the read timeout will expire. Is there any other option when using
ReadTimeout besides disabling keep-alive?

--

Search Discussions

  • Kyle Lemons at Jan 1, 2013 at 9:49 pm
    Based on the code, ReadTimeout and WriteTimeout are applied once after a
    connection is accepted.

    Are you actually trying to benchmark the dialing mechanism, or just your
    server under load? If the latter, I would make an in-process Listener that
    returns net.Pipes.

    On Mon, Dec 31, 2012 at 1:12 PM, Patrick Higgins wrote:

    I've discovered that setting a ReadTimeout on an http.Server and serving
    many keep-alive requests on it results in the connection being reset by the
    server after the read timeout expires.

    To work around this, I am disabling keep-alives in the server by setting a
    "Connection: close" header.

    However, this makes it difficult to benchmark locally because of port
    exhaustion.

    This behavior seems surprising to me--I would have expected the read
    timeout to reset after each request. I also don't see a way to determine
    how many requests have been served over a single connection, nor how long
    until the read timeout will expire. Is there any other option when using
    ReadTimeout besides disabling keep-alive?

    --

    --
  • Patrick Higgins at Jan 18, 2013 at 9:04 pm
    I actually want to benchmark the full stack (the test program is
    out-of-process). I was able to work around it by setting the
    net.ipv4.tcp_tw_reuse sysctl to 1 when benchmarking.
    On Tuesday, January 1, 2013 2:48:37 PM UTC-7, Kyle Lemons wrote:

    Based on the code, ReadTimeout and WriteTimeout are applied once after a
    connection is accepted.

    Are you actually trying to benchmark the dialing mechanism, or just your
    server under load? If the latter, I would make an in-process Listener that
    returns net.Pipes.


    On Mon, Dec 31, 2012 at 1:12 PM, Patrick Higgins <patrick.al...@gmail.com<javascript:>
    wrote:
    I've discovered that setting a ReadTimeout on an http.Server and serving
    many keep-alive requests on it results in the connection being reset by the
    server after the read timeout expires.

    To work around this, I am disabling keep-alives in the server by setting
    a "Connection: close" header.

    However, this makes it difficult to benchmark locally because of port
    exhaustion.

    This behavior seems surprising to me--I would have expected the read
    timeout to reset after each request. I also don't see a way to determine
    how many requests have been served over a single connection, nor how long
    until the read timeout will expire. Is there any other option when using
    ReadTimeout besides disabling keep-alive?

    --

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 31, '12 at 9:12p
activeJan 18, '13 at 9:04p
posts3
users2
websitegolang.org

2 users in discussion

Patrick Higgins: 2 posts Kyle Lemons: 1 post

People

Translate

site design / logo © 2022 Grokbase