Not sure what you mean by "it". The latency numbers might *never* stabilize depending on how your topology is written and the data it is processing. As I said, this is highly dependent on a bunch of stuff. The latency numbers might stabilize within minutes if the topology is trivial. Or it might take hours (e.g., if your topology is doing a lot of work that is dependent on having data pre-cached). Or it might never stabilize if the data flow and content is highly variable.
- Erik On Mon, Mar 21, 2016 at 4:49 PM, sam mohel <[email protected]> wrote: > Thanks but how can I decide it . or what are the conditions that make me > know it ? > > > In Tuesday, March 22, 2016, Erik Weathers <[email protected]> wrote: > >> That *entirely* depends on your topology and environment. >> >> - Erik >> >> On Mon, Mar 21, 2016 at 4:27 PM, sam mohel <[email protected]> wrote: >> >>> I mean numbers which I got in complete latency and execute latency . >>> when I submitted topology those numbers changed every time I refreshed page >>> of storm ui . when it becomes stable to measure performance of topology >>> >>> Tuesday, March 22, 2016, Justin Hopper <[email protected]> wrote: >>> >>>> Sam, >>>> >>>> Which numbers are you speaking of? And by “get the numbers rightly”, >>>> what do you mean by that? >>>> >>>> Thanks, >>>> >>>> Justin >>>> >>>> On Mar 21, 2016, at 14:30, sam mohel <[email protected]> wrote: >>>> >>>> Thanks again. Last question about storm ui . when I submitted topology >>>> numbers that appeared changed every time I refreshed page . so how can I >>>> get numbers rightly ? >>>> >>>> On Monday, March 21, 2016, Justin Hopper <[email protected]> >>>> wrote: >>>> >>>>> Right. >>>>> >>>>> On Mar 21, 2016, at 14:16, sam mohel <[email protected]> wrote: >>>>> >>>>> Really thanks for your reply . I will try it now . but I'm asking >>>>> about that if I run supervisor with high core then it will give me high >>>>> performance for topology right ? >>>>> >>>>> On Monday, March 21, 2016, Justin Hopper <[email protected]> >>>>> wrote: >>>>> >>>>>> I am recommending that you that try that approach first (storm + zoo >>>>>> on core2 duo; super on i5). I would expect more thread contention >>>>>> (decrease >>>>>> performance) if you choose to reverse the deployment strategy. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Justin >>>>>> >>>>>> >>>>>> >>>>>> On Mar 21, 2016, at 11:18, sam mohel <[email protected]> wrote: >>>>>> >>>>>> Thanks for replying . so I should run nimbus ,zookeeper on machine >>>>>> core2duo and supervisor on core I 5 but Are results will change if I run >>>>>> it >>>>>> in reverse . >>>>>> >>>>>> On Monday, March 21, 2016, Justin Hopper <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Sam, >>>>>>> >>>>>>> Nimbus and Zookeeper mostly perform management of the cluster itself >>>>>>> - not performing real work. Given your situation, place the Supervisor >>>>>>> on >>>>>>> the high-performant system (core i5). >>>>>>> >>>>>>> Justin >>>>>>> >>>>>>> On Mar 20, 2016, at 23:15, sam mohel <[email protected]> wrote: >>>>>>> >>>>>>> Is there any help ? >>>>>>> >>>>>>> On Monday, March 21, 2016, sam mohel <[email protected]> wrote: >>>>>>> >>>>>>>> I have 2 machine one has core 2duo and other has core i5 . which >>>>>>>> one should I run nimbus and zookeeper on it and which one should I run >>>>>>>> supervisor ? >>>>>>>> >>>>>>>> Should worker run on machine with high core or it shouldn't ? >>>>>>>> >>>>>>>> Appreciate your help >>>>>>>> Thanks in advance >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>
