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-t...@mcs.anl.gov > [mailto:owner-ag-t...@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 > secur...@triumf.ca > >
