On Thu, 10 Apr 2008, David Nolan wrote: > I'm using mon with well over 100 hostgroups without any performance > problems, with mon.cgi rendering a full page in under a second > typically. I can't see how the performance would fail to scale to > 600.
one problem with the current client library is that the commands are processed synchronously, where the library call for say, getting opstatus, will not return until the entirety of the response is returned by the server. so, if you have a relatively high-latency link between the client and the server, and you're submitting a bunch of commands when the user clicks "show me this" in a client in order to get enough things for the report, the "show me this" routine can become latency-bound. monshow is an example of this. to generate the summary page, it asks for a bunch of things such as the opstatus, what is disabled, the scheduler state, group and service list, dependency list, etc. this is noted in the todo. a reasonable way to deal with this is probably to change the protocol so that multiple commands can be issued as one transaction, and the reply would be the list of the data returned along with the completion status of each of the commands, i.e. whether it worked fine or if there was an error. an alternate solution would be to not change the protocol but modify the clients to submit multiple commands over multiple connections in parallel. this would require some changes on the server end as well. actually, a combination of this suggestion and the previous would be better. _______________________________________________ mon mailing list mon@linux.kernel.org http://linux.kernel.org/mailman/listinfo/mon
