[AG-TECH] Venue client too slow

[Ivan R. Judson]

Hey Andrew, 

This is a great table. I appreciate your taking the time to put it together,
and I promise we're heavily influencing our current cycle with this
information. We're aware the user software is way too slow, and we're
working on it -- it's one of our priorities.

There are what appear to be 2 major performance hits we're taking:

1) GSI is slow, it's not a fast enough protocol for interactive systems
(IMHO)
2) Our current SOAP solution is doing very slow XML<->python serialization

Additionally, it looks like you identified a startup problem with the image
loading information, we can look into that, but I'm wondering if you
compared the startup with a non-ag wxpython application to see what the
"baseline" is for a wxpython app (there's a great demo that might be good
for this)?

Again, thanks, this is a great table, is it something I can use in ppt?

--Ivan 

> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov 
> [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Andrew Daviel
> Sent: Friday, December 03, 2004 12:57 AM
> To: AG Tech List
> Subject: [AG-TECH] Venue client too slow
> 
> 
> 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
> 
>