El mié, 16-04-2008 a las 14:42 -0700, vagrant@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.
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente