Stress-Testing LTSP was Re: No Sound with Flash in Firefox

[Gavin McCullagh]

Hi,

On Fri, 13 Jul 2007, Jim Kronebusch wrote:

> Gideon Romm's modified ldm adds the ability to do auto logins with LTSP
> 5, you could use this to tackle the autologin part.  

Yes, this is what I'd have in mind.  Hopefully ldm2 will have such a
feature.

One of the awkward bits is how to create separate users for each thin
client.  It's not ideal for them to all login on the same account as
neither gnome nor firefox will like that.  If anyone has a clue on how to
do this I'm all ears, eg 

 - Can you create a single account /home/testing/ and make subdirectories
   off it /home/testing/1/ /home/testing/2/ and run gnome and the
   applications in a separate sub-home directory?

 - Perhaps the nbd home directories provide a simple solution?

> In the past I have booted up clients and logged in manually and started
> up Kstars since it is constantly changing, at least I could get an idea
> of performance that way.  I would then sit at a terminal and check
> webmail and type some garbage into openoffice and just see how it felt
> while I used it and 30 other machines were running KStars.  

That's a reasonable starting point, I'd just like it to be a bit more
automatic and user driven.  I wrote a brief script last night which every
second tests a random number and either does nothing, starts firefox, opens
urls randomly from a list or closes firefox depending on the number.  I can
probably add in openoffice opening a random file and openoffice closing
without too much trouble, though more detailed work is difficult.  I
suspect RAM footprint is your major problem so having openoffice open and
importing files now and then may be a reasonable simulation of a user --
you would hope simple things like typing should cause minimal load.

> I like the idea of wake on lan but even if it could be done with a manual
> boot it would be better than nothing.  

It doesn't really involve any work (you just tell the thin client's BIOS to
use wake-on-lan) so anyone who knows how can just use it.

> This would be great if coupled with some sort of tool for checking server
> parameters.  

Something like Munin would seem to be the tool for this (I would suggest
you should look into munin for a server of your size anyway).  Although in
some ways, sitting down and trying to use the system alongside N simulated
users may be more instructive.

> Most of our users I think have at least two apps open at a time, most
> often it will be a browser with one or two tabs and a text editor.

We can start off keeping things really simple but what might be nice if we
get past the first few hurdles would be to have different usage profiles
(basic web user, power web user, office user) which you can choose from.

> It would be nice to have a standard way of testing and be able to put
> together some sort of matrix that could state for average student use a
> server of size X could handle X amount of users.  

Yes and give details like "based on 50% of users running firefox loading
pages approximately every 30 seconds".  I have no idea what a "real"
user's activity looks like, eg if they're surfing how many pages do they
load per second?  The pages probably tend to come in bursts too, rather
than spread out evenly.

I would hope the basic test we could get an answer to is with N users
logged in with gnome and openoffice/firefox running and intermittently
active, how "usable" is system Y?  You could try switching to XFCE or KDE
and see can you get more users.  If you can get it to start performing
poorly, munin would hopefully give you an idea what the problem was (RAM,
CPU, disk access).

Gavin