[AG-TECH] Venue client too slow

[Andrew Daviel]

The Venue client is too slow !

(AG 2.3 Linux package from UQ FC1 RPM)

While trying to debug the single-CPU problem, I made some timings of the
venue client on a 2.4GHz P4 756Mb system, talking to an AG 2.2 venue
server on the same LAN, running on a lightly loaded 1.8GHz P4.

      Tasks                            Time to change rooms
VenueClient.py --insecure               3 seconds
VenueClient.py                          11 seconds
VenueClient.py + Vic                    13 seconds
(VenueClient.py + Vic + Rat              4.5 minutes)

IMO, this is far too long. UIs should take less than 300ms to perform an
operation, and if they can't due to some inherently slow process (opening
a gate, draining a pond...) they should produce some kind of active
status display and immediately return to accepting key/mouse events, such
as a request to abort. Modern browsers such as Mozilla have got bloated
and way too slow to load IMO, but at least they can load a new page in
the order of 300ms (on a good net, with no page swapping), or open a new
view etc., even if they are throwing around multi-megabyte bitmaps and
consume half the virtual memory with rendered pages.
Also, SSL in Mozilla and Apache doesn't add appreciably to the delay in
getting a Web page (though it is a significant burden on a busy server
with hundreds of clients), while in the venue client it adds 8 seconds.
Perhaps the SSL handling in Python needs to be re-written, or implemented
as an OS-dependant module. It shouldn't need hardware acceleration for
just a few dozen clients ....

 --

I thought I would run strace on the venue client to see what it was
doing. From starting the client, to the UI appearing on the screen
(befoer it has connected to a server), it checks 4000 files, opens 1800
of them, and does some 6000 read operations. This seems absurd. Half of
those were PNGs in the bluecurve theme, or Chinese and Eastern European
font files in /usr/share, which aren't even used (this is running in
English, or at least Western European). This could account for some of
the startup delay.
In contrast, to start just Python uses 50 opens.

There were a somewhat more restrained 35 or so file opens to change
rooms.

There aren't enough timeouts in the venue client, or there are too many
uninterruptible loops (when the UI is dead to key/mouse events).
If the server doesn't exist (can't be resolved) the client returns quite
quickly with an alert. But if something goes wrong after connecting, then
the client appears to jam up and does not refresh or respond to mouse
events. It may recover after an extended period (4 minutes in the Rat
problem) or it may not, and have to be killed with the window manager
or from the command line.

This kind of thing is very frustrating for users - one of our people who
uses VRVS a lot has trouble understanding why anyone would want to use AG
instead...



-- 
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376
security at triumf.ca