Hi Andrew,
In testing AG 2.2, I found it to be very slow too. Since you mention
'an AG 2.2 venue server', I wonder if that might be an issue. What about
timings to the main/other AG venue servers?
In moving to AG 2.3, things were much faster, and much more in the
'acceptable' response range.
Derek
Andrew Daviel wrote:
> 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...
>
>
>
--
Derek Piper - dcpi...@indiana.edu - (812) 856 0111
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana
