Hi Akila, How did you come up with the value of 75 (150/2 ?)? What's the basis for assuming that all 150 requests are served correctly? (Server might be capable of handling only 20 concurrent requests at a moment.
On Thu, Jun 5, 2014 at 12:00 PM, Akila Ravihansa Perera <[email protected]> wrote: > Hi Asiri, > > Great work on the proposal. I have some few concerns/suggestions. > > RIF metric is calculated by taking the number of requests currently in > the LB's queue, AFAIK. Therefore, rather than taking input for rif > count that an instance could handle, it would make sense to calculate > the number of instances required to maintain the average RIF. > > For eg. let's say we have 2 instances, and RIF avg is 150, and > predicted RIF goes to 170. It means using 2 instances, one instance > may have to take 85 RIF. But avg RIF for one instance should ideally > be 75. Then we can calculate how many instances we need to maintain 75 > RIF per instance. > > This is merely a suggestion. Reason is I don't think taking user input > for RIF per instance would make much sense, IMHO. > > Thanks. > > On Thu, Jun 5, 2014 at 9:51 AM, Asiri Liyana Arachchi > <[email protected]> wrote: > > 1. Improve the auto-scaling to predict the number of instances needed. > > > > Starting a new thread with suggestions to predict the number of > instances. > > > > There are three factors that are being considered when auto scaling. > > Requests in flight (rif) > > Memory Consumption > > Load average. > > > > For requests in flight. > > > > User input - Number of rif than an instance could handle. > > > > Once it's given we can simply calculate the required number of instances > to > > spawn or terminate. > > > > For an e.g. > > Number of rif that an instance could handle - 50 > > Predicted rif =170 > > Required instances = 170 /50 > > = 4 (taking the ceiling value ) > > > > If the current number of instances is 2 another 4-2 have to be spawned. > > If the current number of instances is 6 , the number of instances that > > should be terminated is 4-6 > > > > When rounding of values ( number of instances ) we can either follow the > way > > amazon did it for percentage based auto scaling [1] or we can let user > > decide (in autoscaling policy) whether to use ceiling or floor value to > > round off depending on his server availability requirements. Welcome your > > thoughts on this. > > > > Here is the project's work that i'm supposed to complete. > > > > 1) setting up apache stratos on openstack. > > 2) research on how to use load average / memory consumption for instance > > calculation. > > 3) Getting community feed back and implementation. > > 4) Research on improving prediction algorithm. > > 5) Schedule based autoscaling. > > > > Currently working on setting up apache stratos.(for testing) > > > > [1] > > > http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/as-scale-based-on-demand.html > > > > -- > Akila Ravihansa Perera > Software Engineer > WSO2 Inc. > http://wso2.com > > Phone: +94 77 64 154 38 > Blog: http://ravihansa3000.blogspot.com > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
