bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

some performance problems with async console client


From: Marcus Brinkmann
Subject: some performance problems with async console client
Date: Fri, 14 Jun 2002 09:44:45 -0400
User-agent: Mutt/1.3.25i

Hi,

I just added the seqno serialization in the console client,
and noticed that there is a severe performance problem.
The issue is that the console server is rocking fast, and the client
can not keep up with this speed in updating the display.
Take a "find /share > term" command.  It will write the data in large
chunks (don't know how large, but larger than 256), which will be split
up into 256 bytes blocks, and each of this blocks usually would generate
three update notifications for each client.  So the number of RPCs from
the server to the client is a multitude of the RPCs from the terminal to
the console server.  This results into a massive thread explosion in the
client similar to the pageout thread explosion.

The next step to solve this will be to cut down the number of RPCs.  I
will try to send only three rpcs for each write to the console (rather
than each 256 bytes block).  The three rpcs are:  writes done,
scrolling done, cursor position.  By rearranging the fields in the file,
I can group the scrolling and cursor position into one RPC.
However, as now the scrolling done can be larger than the screen itself,
I need to change the semantics of cur_line, which will be incremented
only as long as uint32_t doesn't overflow (this is important, because
otherwise if it changes from 1 to 2, the client doesn't know if it
actually grew from 1 to nlines + 2).

However, this will still result into two RPCs per write.  I am not very
confident that this will eliminate the problem, as the client will
always be slower than the server.  One cheap way out is to make update
notifications synchronous, so the server will become much slower, but
screen updates will be synchronous.  Maybe for a first version this is
good enough.  Another way to improve the situation is to make reception
of update notifications and the actual screen updates asynchronous in
the client, too.  This requires a bit more logic, but adds flexibility
in that the client can notice if a lot of output appears, and change the
way it updates the screen to a more polling-like mode in this case.

All of this is possible, and I don't know what is best.  It is likely
that I change it to be synchronous soon, as this is the simplest
solution and should work acceptably for now.  It would be a compromise
between having everything in one program and being fully asynchronous
(which Roland rightly pointed out to be more ambitious).

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]