Hi! On Sat, Sep 27, 2008 at 02:01:09AM +0200, Till Neudecker wrote: > I have a pretty normal loadbalancing setup (2 relayd-loadbalancer, 2 backend > hosts). The loadbalancer accepts ssl-encrypted sessions and forwards them > unencrypted to the backend-hosts. Because all the hosts are on the same LAN > I set the global timeout-directive to 200ms. >
200ms is a really brave timeout even for host checks in a LAN. I almost always increase it in my configurations, but I think pyr@ liked the really short timeout ;). But we should probably bump up the default to prevent failures in common configurations. > When now connecting from a slow internet-connection to my service, I often > receive a "SSL accept timeout". After changing the global timeout to 2000ms > the problem disappears. The man-pages only says timeout limits the time for > the checks of the backend-hosts but nothing about the SSL-handshake from > clients. > > Can someone agree or disgree to my guess that timeout also limits the time > for the SSL-handshake? > Yes, this is right. The global timeout is a "connection timeout" which is used by the health checks but also by the initial connect/accept of the relays in TCP and SSL mode. This means that this timeout will be used for the time to establish the stateful TCP or SSL connection. The established connection will switch to the per-relay "session timeout" which defaults to 600s (10min) for idle TCP/SSL sessions. Thanks for your hint, I will think about adding another timeout and/or improving the manpage here. Reyk
