> On May 13, 2014, 2:02 p.m., Dominic Hamon wrote: > > In regards to adding a layer of indirection: I'm not completely opposed to > > the idea, but I'd like to avoid the tautology. So it would be: > > > > master/messages/kill_task > > master/messages/reconcile_tasks > > master/messages/authenticate > > > > > > what do you think?
SGTM. > On May 13, 2014, 2:02 p.m., Dominic Hamon wrote: > > src/master/master.hpp, line 535 > > <https://reviews.apache.org/r/21399/diff/1/?file=580888#file580888line535> > > > > why add the blank line here? is there a way to group these logically > > that we can use on declaration, here, and below when removing? maybe: > > > > *_framework_messages > > > > *_slave_messages > > > > *_task(s)_messages > > > > other_messages I am grouping them as // Messages from schedulers. // Messages from slaves. // Messages from both schedulers and slaves. In member definition within these sections I further divided these messages into lifecycle related messages and steady state messages but didn't added more comments for them. I think I can remove this subdivision. I will make sure the grouping is consistent in declaration and add/remove. > On May 13, 2014, 2:02 p.m., Dominic Hamon wrote: > > src/master/master.cpp, line 1212 > > <https://reviews.apache.org/r/21399/diff/1/?file=580889#file580889line1212> > > > > to be clear - we're counting the messages we receive even if we don't > > act on them. is that expected? I think this is expected because we measure "requests" - Jiang Yan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21399/#review42884 ----------------------------------------------------------- On May 13, 2014, 1:59 p.m., Jiang Yan Xu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21399/ > ----------------------------------------------------------- > > (Updated May 13, 2014, 1:59 p.m.) > > > Review request for mesos, Ben Mahler and Dominic Hamon. > > > Bugs: MESOS-1338 > https://issues.apache.org/jira/browse/MESOS-1338 > > > Repository: mesos-git > > > Description > ------- > > See summary. > > > Diffs > ----- > > src/master/master.hpp 4f9ae36c822a16ea3baadf6b9fa3616d030d19f2 > src/master/master.cpp d5453673a839326d00a3d45940bd4562c526cff2 > src/tests/master_tests.cpp 7aa678afc94869c8243485bd0604532dec43a1e2 > > Diff: https://reviews.apache.org/r/21399/diff/ > > > Testing > ------- > > make check & visual verification. > > The stats look like this: > > { > master/authenticate_messages: 0, > master/deactivate_framework_messages: 0, > master/dropped_messages: 0, > master/event_queue_size: 0, > master/exited_executor_messages: 0, > master/framework_to_executor_messages: 0, > master/kill_task_messages: 0, > master/launch_tasks_messages: 0, > master/reconcile_tasks_messages: 0, > master/recovery_slave_removals: 0, > master/register_framework_messages: 0, > master/register_slave_messages: 0, > master/reregister_framework_messages: 0, > master/reregister_slave_messages: 1, > master/resource_request_messages: 0, > master/revive_offers_messages: 0, > master/slave_registrations: 0, > master/slave_removals: 0, > master/slave_reregistrations: 1, > master/status_update_messages: 0, > master/unregister_framework_messages: 0, > master/unregister_slave_messages: 0, > registrar/queued_operations: 0, > registrar/registry_size_bytes: 338, > registrar/state_fetch_ms: 0.067019, > registrar/state_store_ms: 0.26969, > registrar/state_store_ms/count: 2, > registrar/state_store_ms/max: 0.26969, > registrar/state_store_ms/min: 0.031574, > registrar/state_store_ms/p50: 0.150632, > registrar/state_store_ms/p90: 0.2458784, > registrar/state_store_ms/p95: 0.2577842, > registrar/state_store_ms/p99: 0.26730884, > registrar/state_store_ms/p999: 0.269451884, > registrar/state_store_ms/p9999: 0.2696661884 > } > > Feels like we could group message counters the following way: > master/messages/authenticate_messages > > Better? > > > Thanks, > > Jiang Yan Xu > >
