Traffic Server
  1. Traffic Server
  2. TS-505

Worse performance when Origin server sends Connection: keep-alive

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.6
    • Component/s: Network
    • Labels:
      None

      Description

      I have a test setup using lighttpd (stock config, but with the port changed to port 82, and logging disabled). I've created a small file (42 bytes) in /var/www/lighttpd/cl-test.html.

      I'm running Apache TS with a stock config ("gmake install") with the following configuration changes:

      records.config:
      ---------------
      CONFIG proxy.config.http.server_port INT 80
      CONFIG proxy.config.http.cache.required_headers INT 2
      CONFIG proxy.config.log2.logging_enabled INT 0

      remap.config:
      -------------
      map http://loki.ogre.com/lighttpd/ http://localhost:82/

      I'm "benchmarking" this using "ab" from a second host, running a command like

      ab -c 20 -n 10000 http://loki.ogre.com/lighttpd/cl-test.html

      Test 1: I disable Keep-Alive in lighttpd, adding a configuration like this to /etc/lighttpd/lighttpd.conf:

      server.max-keep-alive-requests = 0

      Test results are

      Requests per second: 9056.01 /sec (mean)
      Time per request: 2.208 [ms] (mean)
      Time per request: 0.110 [ms] (mean, across all concurrent requests)

      Test 2: I enable Keep-Alive in lighttpd, with

      server.max-keep-alive-requests = 1000000

      Test results are:

      Requests per second: 4456.33 /sec (mean)
      Time per request: 4.488 [ms] (mean)
      Time per request: 0.224 [ms] (mean, across all concurrent requests)

      This might not seem like a huge difference, but why would it be serving 2x fewer QPS and 2x the latency with keep-alive to the origin server? If anything, I'd expect it to be faster with keep-alive, right ? Shouldn't that be noticeably less work?

        Activity

        Hide
        Leif Hedstrom added a comment -

        I should point out that there is a) no Keep-alive to the client in any of the tests and b) The content is not cacheable to traffic server (I've set it to require explicit Cache-Control or Expire: headers). This means every request is proxied, and nothing ever gets written (or read) from disk.

        There is never any disk I/O in any of the tests (no reads and no writes), according to iostat -x.

        Show
        Leif Hedstrom added a comment - I should point out that there is a) no Keep-alive to the client in any of the tests and b) The content is not cacheable to traffic server (I've set it to require explicit Cache-Control or Expire: headers). This means every request is proxied, and nothing ever gets written (or read) from disk. There is never any disk I/O in any of the tests (no reads and no writes), according to iostat -x.
        Hide
        Leif Hedstrom added a comment -

        One observation here is that allowing ATS to reuse (share) keep-alive connections makes things a whole lot better. E.g.

        CONFIG proxy.config.http.server_max_connections INT 10000

        Show
        Leif Hedstrom added a comment - One observation here is that allowing ATS to reuse (share) keep-alive connections makes things a whole lot better. E.g. CONFIG proxy.config.http.server_max_connections INT 10000
        Hide
        Leif Hedstrom added a comment -

        This is resolved for now, with a change in the default configurations. Opening a separate ticket to examine when we ought to do the writer lock, but can target that for v3.1.

        Show
        Leif Hedstrom added a comment - This is resolved for now, with a change in the default configurations. Opening a separate ticket to examine when we ought to do the writer lock, but can target that for v3.1.

          People

          • Assignee:
            Leif Hedstrom
            Reporter:
            Leif Hedstrom
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development