On Wed, Oct 29, 2008 at 2:38 AM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > On Tue, 2008-10-28 at 23:55 -0700, Garrett Cooper wrote: > >> This should be my last note for the night. >> Doing performance tests with upstart and initctl I noticed that >> initctl reload eats up a ton of CPU cycles compared to initctl start >> or initctl when running in a while [ 1 ] bourne shell loop. >> > Do you mean that initctl uses more resources, or that init uses more > resources when executing the command? > > reload is to reload all job definitions from disk, it's really quite > expensive compared to start - which just changes a job state.
What I meant is overall initctl reload uses up a large amount of resources; I was just wondering if there was a more lightweight alternative planned because we may potentially be reloading the configuration frequently, in such a case it wouldn't make sense to reload all of the files necessarily -- just the ones that have changed. >> We >> currently use initctl reload for getting new jobs loaded into upstart >> init; however, I was wondering whether or not: >> 1. The method of getting new job definitions was the best choice. >> > Upstart should reload them itself by watching the directory with > inotify. Hmm... ok. So this isn't implemented, but it's slated? >> 2. Code coverage tests have been performed on upstart. >> > Yes, the existing test suite has high code coverage. Ok, good :). >> 3. Optimizations have been discussed or planned for future minor >> revisions of upstart, s.t. better methods could be employed "under the >> covers" to reduce upstart's resource cost. >> > They have not been discussed, but are always welcome. Yes, I do think your suggestion for using inotify would be a welcome improvement over having to use initctl reload. Let me see what my group says and we'll get back to you about this. > Scott Thanks! -Garrett -- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
