On Friday 04 August 2006 19:54, Andrea Righi wrote: > What about doing a mkfifo /var/lib/systemimager/clients.xml when > si_monitor starts? then we should add an option in si_monitortk to save > the clients data, but this is quite easy to implement...
A fifo with every receive client writing to it? No, I actually meant: when spawning a receive thread (which now rewrites the config.xml file after getting the data from a client) open a pair of pipes to the master thread. Let the client write the new data to the pipe and the master thread drain this after the client receiver process exited. This way the master thread keeps the information on client status fresh without any file being written. It could write the clients.xml file once a second or upon request (from the tk client application). This way the filesystem load would stay low and would not increase with the number of client nodes. Of course, you can use IPC::Shareable or Cache::Mmap or other IPC mechanisms, but I'm not sure whether these perl modules are really spread on all major distros. I actually doubt it. And in that case you need again to take care of synchronization and locking. Regards, Erich > > And I agree, the protocol can be improved a lot, at the moment we're > using the simplest implementation... another improvement could be to use > UDP instead of TCP, I tried in the past to move to UDP, but I had some > problems with netcat in particular for closing netcat at the end of the > message (if I remember well)... maybe we can spend some time and > investigate on that... but IMHO after 3.7.4 ;-) > > -Andrea > > Erich Focht wrote: > > On Wednesday 02 August 2006 20:33, Andrea Righi wrote: > >> Erich, > >> > >> thanks for the simulator! from a quick test it seems that the fs > >> overhead is quite high... for example moving clients.xml in /dev/shm > >> strongly reduce the load and cpu time of si_monitor and si_monitortk.. > >> so the idea to move the data in RAM seems reasonable.. > > > > Good! /dev/shm would probably already help a lot. But not writing at all > > would > > be even better, still for that you need some IPC method between the receiver > > threads and the master thread. pipes seem to be the simplest tom implement. > > > > BTW: You are sending two requests right behind each other. One for status > > and > > one for speed. Each triggers a write. Guess you could easilly extend the > > protocol to save one ;-) > > > > 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
