[Pkg-ltsp-devel] Stress test in ltsp

[José L. Redrejo Rodríguez]

El mié, 16-04-2008 a las 14:42 -0700, vagrant at freegeek.org escribió:
> On Wed, Apr 16, 2008 at 07:35:28PM +0200, José L. Redrejo Rodríguez wrote:
> > In the last two weeks I've been doing some stress tests in the
> > classrooms where I'm using ltsp, and I'd like to share the results and
> > my conclusions. 
> ...snip...
> > When using a 1 Gbps port in the switch to connect the server to the thin
> > clients:
> > - THere was some 98 Mbps NFS peaks, and some 124 ssh peaks, but they
> > didn't last in time. All the clients started, no one was stalled. The
> > starting time was reduced from 1'40" to 45" with the Open Office
> > application running.
> > - There was a ¿funny? result: the Xeon machine raised its CPU use to
> > 100% when Openoffice started, with the Quad Core  the CPU didn't raise
> > more than 20%. Because of it, when using the Xeon server some of the
> > clients where stalled for several seconds when starting X. Anyway, the
> > starting time was about 5" less when using the Xeon for the clients that
> > didn't stall.
>  
> > Conclusions:
> ...snip...
> > - The Xeon server seems to behave better in network use, but worse when
> > starting big desktop applications with a lot of graphics.
> > - RAM is not very important. The use of RAM was never more than 2
> > Gbytes, remaining more than 1,8 Gbytes of not used RAM.
> > - When there's no concurrency, both the Xeon and the Quad Core have not
> > CPU problems, less than 5% starting OpenOffice (even if some other
> > instances are already started), but when there is concurrency, the Xeon
> > server behaves much worse. I don't know the reasons and would like to
> > know any opinion. 
> 
> i'm wondering if there are differences in the on-board sata that is
> causing a disk i/o issue... could try "dstat", which can report on
> various types of i/o...
> 

Yes, it could be informative

> could also copy the server's /opt/ltsp to a tmpfs and turn off the
> server's swap, and see if that makes a difference in performance, as the
> client OS will be loading from the server's ram.


That's a very good idea. I'll try it today

> 
> i'd also be curious to see the performance using an i386 machine rather
> than amd64, or the same servers with an i386 install of debian.
> 


mmm, do you think that using a -bigmem i386 kernel might have better
perfomance than using an amd64, with 4-8 Gbytes of RAM?
Theorically, memory pagination with -bigmem is  much  worse...
Using i386 would make life easier with java and flash plugins, but I
discarded it giving preference to perfomance.

Regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/attachments/20080417/0d4518de/attachment.pgp