## Optimal Elasticity Planning

*By dcerezo On 31/03/2013 · Leave a Comment · In charts, cloud*

Elasticity and scalability via dynamic provisioning of servers and other resources is one of the tenets of cloud computing: in practice, being able to automatically grow the resources available to an application based on the level of demand is actually eased with patterns like WASABi, the Autoscaling Application Block for Azure.

But even if an application can automatically grow, a question is still unanswered: **what is the minimum number of servers that should be reserved**? And that is a complex question that requires trading off the losses of being unable to properly service requests because booting up instances takes some minutes, and the actual costs of those instances that may rest idle with no load.

Let’s consider a service with low margin (10%) and a really intensive computation (8 requests per second per Azure XL server) were the probability that a customer does not enter the service due to congestion is 1% and a much higher probability of 2.5% for those leaving the service after a request: to model the whole system an M/M/s queue is considered, that is, *s* servers experiencing a Poisson-like input process and an exponential service time, with an unlimited waiting queue. To solve the proposed queue model, R code and its resulting plot as follows:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | # Minimum number of roles to calculate minRoles <- 4 # Maximum number of roles to calculate maxRoles <- 12 # Probability of not entering service due to high-load probNotJoin <- 0.01 lossNotJoin <- 0 # Probability of leaving the service due to high-load probLeaving <- 0.025 lossLeaving <- 0 # Revenue per request customerRevenue <- 1 # Profit per request customerProfit <- 0.1 # Azure XL web/worker role ($0.96/hour) costServer <- 0.96 # New requests/hour arrivalRate <- 90000 # Requests/hour serviced per role serviceRate <- 30000 serviceCost <- 0 totalCost <- 0 library(pdq, help) for(r in minRoles:maxRoles) { Init("") CreateMultiNode(r, "server", CEN, FCFS) CreateOpen("requests", arrivalRate) SetDemand("server", "requests", 1/serviceRate) Solve(CANON) queueLength <- GetQueueLength("server", "requests", TRANS) - arrivalRate/serviceRate waitingTime <- 60 * queueLength/arrivalRate numNotJoin <- queueLength * probNotJoin * arrivalRate numLeaving <- waitingTime * probLeaving * arrivalRate serviceCost[r] <- r * costServer lossNotJoin[r] <- numNotJoin * customerRevenue * customerProfit lossLeaving[r] <- numLeaving * customerRevenue * customerProfit totalCost[r] <- serviceCost[r] + lossNotJoin[r] + lossLeaving[r] } plot(totalCost, xlim=c(minRoles,maxRoles), type="b", col="black", lwd=2, main="Optimal Elasticity of Demand", xlab="Servers (m)", ylab="Cost ($)") lines(serviceCost, xlim=c(minRoles,maxRoles), type="b", col="brown", lty="dashed") lines(lossNotJoin, xlim=c(minRoles,maxRoles), type="b", col="green", lty="dashed") lines(lossLeaving, xlim=c(minRoles,maxRoles), type="b", col="orange", lty="dashed") |

The black curve represents the total costs: the sum of the server costs (brown curve) and losses due to not entering the service (green curve) and leaving the service (orange curve). An optimal reservation of servers is found at **s=8**, the minimum of the total curve costs.

## Charts: Koomey’s Law

*By dcerezo On 03/10/2011 · Leave a Comment · In charts*

As a follow-up to my previous post about basic computer engineering laws, this recent chart depicting Koomey’s Law, teaching us that for a fixed amount of computational power, the need for battery will fall by half every 1.6 years, or the other way round, the energy efficiency of computers doubles roughly every 18 months; a real breadth of fresh air to the current trend to conserve energy in computing systems.

March 2017 M T W T F S S « Feb 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ### Archives

- February 2017
- April 2014
- March 2014
- December 2013
- November 2013
- July 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011

### Blogroll

- ACM Queue
- Asymco
- Bentham's Gaze
- Bristol Cryptography Blog
- Computational Complexity
- Cryptographic Engineering
- ECRYPT-EU
- Elliptic News
- ePrint IACR
- Financial Times Tech Blog
- Gödel's Lost Letter and P=NP
- IEEE Spectrum
- ImperialViolet
- InfoQ
- Jefferson's Wheel
- Lessons Learned
- Light Blue Touchpaper
- Marginal Revolution
- Musing on Markets
- Nature
- Nick Higham
- Outsourced Bits
- Quanta Magazine
- Renesys Blog
- Schneier on Security
- Science
- Telco 2.0
- The Economist
- The Leisure of the Theory Class
- The morning paper
- Tomasz Tunguz
- Turing’s Invisible Hand
- Unenumerated