How frequently does one client node send status info to the master node? I looked it up: 10s. And I guess this could be more often, but well... maybe it was reduced. Anyway, this means with 200 nodes you'll see 20 connects per second and write an XML file 20 times a second. It is pretty easy to write a simulator for this. With the GUI refreshing every (I guess) 3-5 seconds, you've done 100 unnecessary file writes. On a journalling filesystem (and who would want ext2 nowadays) this can hit you. It might kill you with 1000 nodes. But as said, write a simple simulator and check the CPU load. The CPU load will be unnecessarilly high and the wait-io, too.
Regards, Erich On Wednesday 02 August 2006 18:28, Bernard Li wrote: > Erich and others - if you are able to do some scalability tests with > si_monitor, please give us some feedback! If there are indeed some > scalability issues, we should fix it (we want our software to be scalable > right? ;-) ) > > The problem both Andrea and I have is that we are always testing on a few > nodes and do not always see the issues when you test on a large number of > nodes. But I think we have fixed a few issues already, like the memory leak > and other issues that would cause high load on the image server. > > Hopefully I'll be able to do a test with 50+ nodes soon, and I'll be able to > provide some feedback as well. > > Thanks! > > Bernard > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Andrea Righi > Sent: Wed 02/08/2006 09:24 > To: [EMAIL PROTECTED] > Cc: [email protected]; Matt Jamison > Subject: Re: [Sisuite-devel] Atomic write in si_monitor > > > > A definitive solution to solve the scalability problem could be to have > multiple hierarchical monitor servers... anyhow this is not a very > usable solution at the moment... :-) > > With the current implementation maybe we can improve performances having > all the data in memory, instead of using a file (as Erich said), but > I'm not sure about that... the kernel should cache the file if it's > strongly used and the fs overhead shouldn't be too big... and what about > using a DBMS for the backend, instead of an XML file? In perspective > this could be a better solution, but for now, maybe, the temporary file > solution could be enough, in particular if we can remove the lock file > that IMHO is the real bottleneck now. Obviously we need to do some tests > before... > > Cheers, > -Andrea > > Erich Focht wrote: > > I'm happy somebody finally brought this up. And I'm not yet convinced that > > the > > use of a temporary file will solve the scalability issue (and the issue is > > bad: number of connects per second increase with the number of clients, > > length > > of the XML file grows as well). After all you're writing XML out > > unnecessarilly often. Wouldn't it be better to have a central daemon keeping > > the data in memory and just responding to queries from the GUI instead of > > just > > rewriting a file so many times per second? > > > > Regards, > > Erich ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sisuite-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
