[K12OSN] Re: a little slow when 30+ workstations all load StarOffice 7 at the same time

[Doug Simpson]

One thing you may be able to do to help this is:

On the *server* load a copy of OOo and just leave it running.

This way the shared stuff is already in RAM and subsequent users loads 
will come up faster.

Doug Simpson
Technology Specialist
DeQueen Public Schools
DeQueen, AR 71832
simpsond at leopards.k12.ar.us
Tux for President!

On Wed, 3 May 2006, pogson wrote:

> On Wed, 2006-03-05 at 12:00 -0400, Sean wrote:
> 
> > > > They are a little slow when 30+ workstations all load StarOffice 7
> > > at
> > > > the same time, or when they log out.
> > > 
> > > Can't do much to speed up 30+ students all starting OOo at the SAME
> > > time. It's going to be slow on pretty much any server.
> > > 
> > > The trick is to get the students to start OOo at slightly different
> > > times. Like "okay this half of the class start now" then 1 min later
> > > "now the rest of you". Once the app is launched the load drops way
> > > down.
> > 
> > My first thought was perhaps a wrapper script around Star Office that
> > inserts a randomly weighted pause of up to 10 seconds before starting
> > up SOffice? This would be annoying, however, in normal use, so
> > something
> > a little more sophisticated that could log how many apps were
> > attempting
> > to startup in the last 5 or 10 seconds, and implement some sort of
> > waiting queue before starting additional copies, might be better. Has
> > anyone ever benchmarked how long it takes to start 30 sequential
> > copies
> > of SOffice, vs just banging go on 30 machines at the same time?
> > 
> > A generic app queue control might be a really good thing for making a
> > K12LTSP server work better with low amounts of RAM. Or does one
> > already
> > exist?
> > 
> > Sean Harbour
> 
> How long is this taking? My server takes about 2s/client to load
> OO1.1.3. I think it is a little faster to have everyone load at once
> rather than sequentially because some things can be done in parallel. In
> general LTSP is most productive when the server is going flat out with
> no waiting. Mine does not swap so the executable stays in RAM. I use
> RAID 1 so disk seeks are done in parallel, too.
> 
> I tried an experiment today by creating a bunch of windows with xnest
> and making a script to load OO for a dozen different users but I got my
> xauth all messed up. I am not  very good with all those parameters... As
> near as I can tell it is a little faster to load in parallel. I was able
> to compare two users v one user loading OO from separate clients. It was
> 2s for one user and 3s for two. One has to purge existing soffice
> processes to make sure the system does not simply open another window to
> soffice. That just takes a second.  Abiword starts a new process every
> time and takes less than a second. I made a loop of thirty starts and
> Abiword takes about 24s to make 30 processes and open 30 windows while
> soffice takes just 30s to open 30 windows from one process because these
> were all by the same user:
>  date>>junk;for (( f=0;f<30;f
> ++));do /var/chroot32/usr/bin/oowriter&done;date>>junk; top -b -u nobody
> >>junk;date
> With the Abiword test, it takes a couple of seconds before significant
> CPU utilization happens because stuff is being copied whereas with
> soffice, the cpu runs hard immediately opening windows. Give or take a
> few seconds everything could be done in less than a minute on my system.
> The variation in the time it takes users to login might spread things
> out a bit, though.
> 
> Here are the CPU utilizations for soffice opening windows in 3s steps of
> real time:
> Wed May  3 22:39:49 CST 2006
> Wed May  3 22:39:54 CST 2006
> It took 5s to get soffice started 5 times and top started. grep id junk
> gave this:
> Cpu(s):  2.7% us,  0.2% sy,  0.1% ni, 96.8% id,  0.2% wa,  0.0% hi,
> 0.0% si
> Cpu(s): 92.7% us,  7.3% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,
> 0.0% si
> Cpu(s): 73.5% us, 16.6% sy,  0.0% ni,  5.0% id,  5.0% wa,  0.0% hi,
> 0.0% si
> Cpu(s): 68.3% us, 17.3% sy,  0.0% ni, 14.3% id,  0.0% wa,  0.0% hi,
> 0.0% si
> Cpu(s): 57.1% us, 11.9% sy,  0.0% ni, 30.4% id,  0.0% wa,  0.3% hi,
> 0.3% si
> Cpu(s): 67.9% us, 12.3% sy,  9.9% ni,  9.9% id,  0.0% wa,  0.0% hi,
> 0.0% si
> Cpu(s): 48.7% us,  9.7% sy, 16.3% ni, 18.7% id,  6.7% wa,  0.0% hi,
> 0.0% si
> Cpu(s):  3.0% us,  0.7% sy,  0.0% ni, 96.3% id,  0.0% wa,  0.0% hi,
> 0.0% si
> 
> 
> I have seen systems take 7s to load OO but they had serious bottlenecks
> like not enough RAM or very slow processors. I am using AMD64 3000 with
> 2gB RAM and three hard drives in RAID 1 so I am rarely busy. I am
> designing a system for a new high school. I am looking at four such
> processors and 6 gB of RAM for 100 users. That should be fun.
> -- 
> A problem is an opportunity.
>