Skip to content
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

Fix performance of server-side SSL connection close. #2675

Merged
merged 1 commit into from Sep 8, 2021

Commits on Aug 9, 2021

  1. Fix performance of server-side SSL connection close.

    When the server wants to close a persistent SSL connection
    because it was idle for `persistent_timeout`, the call stack is:
    
        Reactor.wakeup!
          Server#reactor_wakeup
            Client#close
              MiniSSL::Socket#close
    
    The close method is called from within the reactor thread.
    
    In this case, `should_drop_bytes?` is true, because `@engine.shutdown`
    is false the first time it is called.
    
    Then, `read_and_drop(1)` is called, which starts by selecting on the
    socket. Now because this is a server-initiated close of an idle
    connection, in almost all cases there will be nothing to select,
    and hence the thread will just wait for 1 second.
    
    Since this is called by the reactor, the reactor will halt for 1 second
    and not be able to buffer any data during that time, which has huge
    effects on overall worker throughput.
    
    Now I'm not sure what is the use to read from the socket?
    
    * From the docs:
    
        It is acceptable for an application to only send its shutdown alert and
        then close the underlying connection without waiting for the peer's
        response.
        https://www.openssl.org/docs/man1.1.1/man3/SSL_shutdown.html
    
    * The existing code did not seem to send any shutdown alert,
      because the shutdown method was called only on the engine, but the
      engine is not connected to the actual TCP socket. The resulting data
      still needed to be compied
    
    * If the server wants to wait for the client's close_notify shutdown alert,
      then this waiting needs to happen with a non-blocking select in the reactor,
      so other work can be done in the meantime. This is not trivial to
      implement, though.
    
    Note that when the client initiated the close and the data was already
    read into the engine, @engine.shutdown will return true immediately,
    hence this is only a problem when the server wants to close a
    connection.
    devwout authored and Ewout Van Troostenberghe committed Aug 9, 2021
    Copy the full SHA
    173a725 View commit details
    Browse the repository at this point in the history