Shall we go for a call, it will be more productive. On Fri, Feb 13, 2015 at 4:45 PM, Lakmal Warusawithana <[email protected]> wrote:
> Hi Michael > > On Fri, Feb 13, 2015 at 4:14 PM, Michael Hall (michaha2) < > [email protected]> wrote: > >> Hi Imesh, >> >> So ‘transistion compensated’ refers to cartridges, which are >> ’transistioning’ between SPAWNED-ACTIVE, and TERMINATING-TERMINATED. >> >> What it really means, is that if the 'aggregated average’ (Referred to >> this as <metric>PredictedValue in scaling.drl) is compensated: >> >> 1. As if the ‘spawning’ cartridges are providing resouce (although >> they aren’t yet) >> 2. As if the ‘terminating’ cartridges have removed resource (although >> they haven't yet) >> >> Such that the ‘transition compensated aggregated average', will be >> approximately what the actually aggregated average would be if those >> cartridges had become fully ‘active’ or ‘terminated’. This means the >> ‘transition compensated aggregated average’ is always in a sensible state >> to make a scaling decision. >> >> This then allows us to make a scaling decision as often as we’d like >> (much smaller than 90 seconds, could even be every 1 second), because if >> you take the example the we’ve scaled up, the 'transition compensated >> aggregated average’ will instantly adjust to N/N+1 of it’s raw value >> (copied formula from previous email for reference below), so another >> scaling decision will only occur, if the underlying load (aggregated >> average) increases even further. >> >> *transistion-compensated-agg-ave = agg-ave * ( cluster-size / >> cluster-size + cluster-spawned-size - cluster–terminating-size )* >> >> > I think this is good proposal, definitely it will help to calculate more > accurate agg-ave values. Since CEP has the topology information we can > easily calculate this. > > AFAIK, auto scaler take care of cartridge states when calculating required > instances count for a predicted load. > > > >> I’d be more than happy to setup a webex meeting to try and explain this >> better? Or another avenue of communication at your preference? >> >> Kind regards, >> >> Mike >> >> From: Imesh Gunaratne <[email protected]> >> Reply-To: "[email protected]" <[email protected]> >> Date: Friday, 13 February 2015 01:09 >> >> To: dev <[email protected]> >> Subject: Re: autoscale architecture >> >> Hi Mike, >> >> Thanks for the detailed explanation of your question. Currently we do >> not have the capability to do this in runtime for a specific cartridge. >> However we could reduce the global scaling decision interval. This needs to >> be configured at three locations: >> >> 1. Cartridge agent statistics publishing interval (default: 15 seconds) >> 2. CEP execution plan/faulty member detection interval (default: 1 min) >> 3. Autoscaler cluster monitor interval (default: 90 seconds) >> >> I did not clearly get what you mean by 'transition compensated'. Is >> there a way to explain it further? >> >> Thanks >> >> >> On Fri, Feb 13, 2015 at 12:26 AM, Michael Hall (michaha2) < >> [email protected]> wrote: >> >>> Hi Dev, >>> >>> Thanks for your response Imesh, if its ok, I’d like to skip straight >>> to my (rather lengthy) question: >>> >>> Does the autoscaler have, currently or plans to introduce, a means to >>> receive an asynchronous event, signalling that a cartridge has gone from >>> ‘SPAWNED’ to ‘ACTIVE’, after it is launched from a 'scale-up’ decision, so >>> that, scaling decision interval can decrease to approximately the metric >>> update interval, and multiple cartridges are not spawned when only one is >>> needed? >>> >>> In more depth: >>> >>> The reasons for my question being that by knowing a cartridge is in >>> the ‘SPAWNED’ or ’TERMINATING’ state, the aggregated metric averages can be >>> ’transition compensated’ I.e… >>> *transistion-compensated-agg-ave = agg-ave * ( cluster-size / >>> cluster-size + cluster-spawned-size - cluster–terminating-size )* >>> To allow the scaling decisions to occur on a continuous (only throttled >>> by the metric update frequency) basis. >>> >>> It appears that currently scaling decision occurs ~minutes. If this >>> becomes ~seconds, it would vastly improving the maximum rate of ascent a >>> cluster can scale against sudden increase in load. >>> >>> It appears that there is no spawning state awareness, which also means >>> several ‘redundant’ instances get spawned, when instance startup time is >>> greater than the scale decision interval. >>> >>> Finally: >>> >>> Are there difficulties in tracking ‘SPAWNED’ to ‘ACTIVE’ state on a >>> per cartridge basis, how does this align (if its a valid enhancement) with >>> other potential improvements that could be made to the autoscaler? >>> >>> Regards, >>> >>> Mike >>> >>> From: Imesh Gunaratne <[email protected]> >>> Reply-To: "[email protected]" <[email protected]> >>> Date: Thursday, 12 February 2015 18:16 >>> To: dev <[email protected]> >>> Subject: Re: autoscale architecture >>> >>> Hi Michael, >>> >>> Yes you can ask any questions you have on Autoscaling here. >>> >>> I don't think we have documented Autoscaling feature in 4.1.0 at the >>> moment. However you could find some information here [1]. Autoscaling has >>> slightly changed with Composite Application Model. >>> >>> [1] >>> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Autoscaler >>> >>> Thanks >>> >>> On Thu, Feb 12, 2015 at 9:33 PM, Michael Hall (michaha2) < >>> [email protected]> wrote: >>> >>>> Hi Devs, >>>> >>>> Is there a resource or contact that can help me understand the >>>> current, and planned architecture of the autoscaling feature within >>>> Stratos. >>>> >>>> Best Regards, >>>> >>>> Mike >>>> >>> >>> >>> >>> -- >>> Imesh Gunaratne >>> >>> Technical Lead, WSO2 >>> Committer & PMC Member, Apache Stratos >>> >> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Lakmal Warusawithana > Vice President, Apache Stratos > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > > -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
