Re: Reconnect causes slowdown in 7.2.1

On Mon, Jan 06, 2003 at 04:22:37PM -0800, Aaron Burt wrote:
> The slowness is in the response time of console connections.  This
> includes things like the time it takes to make the initial connection
> (time from typing "console dev4-001" to getting a "[Enter `^Ec?' for
> help]") or, once you're connected, from hitting a key and getting a
> response from the machine you're connected to.

are we talking about a second or more like 10 second delays?  see below
for more.

> The slowness affects all 16 consoles managed by a given Conserver process.

that makes sense...when a process is "busy" waiting, it'll hang the
group of consoles it's managing.

> So, is this problem addressed by the reinit changes in 7.2.3?

i'd have to say no.  i believe most things are the same in regards to
this issue, but, of course, there are other things the new stuff has
that could be useful.  but, i'm digressing.

> Or does the sleep in the reinit loop hold up the whole Conserver process?

there are a couple of sleep() calls that would hold up a conserver
process.  each are less than a second, however, and i'd really be
surprised if they were "stacking up" and giving you long pauses
(although a second can seem like a long time too).  if you're seeing
very long pauses, it's more likely the call to connect() that's
hanging.  was your terminal server actively rejecting the
reverse-telnet connections, or is it just half-opening the socket?  if
it's not getting an active rejection, you'll see a 10 second delay
before the conserver process gives up and decides to move on - any
other consoles managed by that process will hang since it's not
multi-threaded or anything (this would be an ideal place to optimize
conserver's functionality with threads).  if you think it's a connect()
issue, you can use the --with-timeout flag to reduce the delay to a
smaller value (like 1) as a work-around - just make sure your normal
terminal server response time is below that value.

if none of this seems to help, you could try tracing the process and
seeing where, exactly, these long delays occur.  or even running in
debug mode could help track it down.  if we can narrow down what part
of the code is actually the culprit, perhaps it can be changed to be
less devastating.

Bryan