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 Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
