high_scalability high_scalability-2013 high_scalability-2013-1566 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: Here's a common situation and question from the mechanical-sympathy Google group by Avinash Agrawal on the black art of capacity planning: How to get started with sizing and capacity planning, assuming we don't know the software behavior and its completely new product to deal with? Gil Tene , Vice President of Technology and CTO & Co-Founder, wrote a very understandable and useful answer that is worth highlighting: Start with requirements. I see way too many "capacity planning" exercises that go off spending weeks measuring some irrelevant metrics about a system (like how many widgets per hour can this thing do) without knowing what they actually need it to do. There are two key sets of metrics to state here: the "how much" set and the "how bad" set: In the "How Much" part, you need to establish, based on expected business needs, Numbers for things (like connections, users, streams, transactions or messages per second) that you expect to interact with at the peak t
sentIndex sentText sentNum sentScore
1 Here's a common situation and question from the mechanical-sympathy Google group by Avinash Agrawal on the black art of capacity planning: How to get started with sizing and capacity planning, assuming we don't know the software behavior and its completely new product to deal with? [sent-1, score-0.438]
2 I see way too many "capacity planning" exercises that go off spending weeks measuring some irrelevant metrics about a system (like how many widgets per hour can this thing do) without knowing what they actually need it to do. [sent-3, score-0.763]
3 Also state expected things like data set size, data interaction rates, and data set growth rates. [sent-5, score-0.437]
4 For the "How Bad" part, you need to make sure your metrics include a description of what acceptable behavior is, remembering that without describing what us not acceptable, you have not described what acceptable is. [sent-6, score-0.885]
5 (Don't get too greedy and ask for "perfect" here, or you'll get a big bill at the end. [sent-9, score-0.094]
6 ) So consider things like how often is it ok for the system to be out of commission for longer than X (for multiple values of X like a year, a week, a day, an hour, a minute, etc. [sent-10, score-0.318]
7 Also consider how often it is ok for the system react in longer than T (for multiple values of T, like an hour, a minus, a second, 50msec, etc. [sent-12, score-0.227]
8 Both of these are usually best stated as levels at percentiles, with availability being stated at percentiles of time, and responsiveness stared at percentiles of actual interactions. [sent-14, score-1.355]
9 Don't forget to state the worst acceptable case for each. [sent-15, score-0.3]
10 This will invariably include repeated testing under a wide range of "how much" levels to see how far things go before they start to fail. [sent-17, score-0.291]
11 The rest, like padding for business requirements underestimating reality, and for being optimistically wrong in various ways in measurement, is a relatively easy exercise of arm wrestling between waiting to sleep well at night and wanting to have more beans left to count. [sent-21, score-0.352]
12 An important note: Before you run the actual experiments and start considering your results, validate that the experimental setup can actually measure what you want. [sent-22, score-0.687]
13 The best way to do that is by artificially introducing certain conditions and verifying that the setup correctly reports on what you know to have actually happened. [sent-23, score-0.364]
14 You may find yourself spending a good amount of time calibrating the experimental setup so that you can actually trust the results, but that us time well spent, as wasting your time (and risking your business) by analyzing and relying on badly measured data is a very expensive proposition. [sent-25, score-0.638]
wordName wordTfidf (topN-words)
[('percentiles', 0.253), ('acceptable', 0.221), ('stated', 0.219), ('metrics', 0.205), ('planning', 0.194), ('bad', 0.165), ('behavior', 0.15), ('capacity', 0.144), ('ok', 0.144), ('hour', 0.13), ('responsiveness', 0.124), ('experimental', 0.116), ('experiments', 0.114), ('measured', 0.113), ('levels', 0.112), ('setup', 0.108), ('actually', 0.104), ('spending', 0.103), ('requirements', 0.101), ('agrawal', 0.094), ('stared', 0.094), ('risking', 0.094), ('wrestling', 0.094), ('tene', 0.094), ('greedy', 0.094), ('set', 0.092), ('things', 0.091), ('considering', 0.089), ('highlighting', 0.088), ('remembering', 0.088), ('invariably', 0.088), ('beans', 0.084), ('slightest', 0.084), ('minus', 0.084), ('values', 0.083), ('expected', 0.083), ('actual', 0.081), ('gil', 0.081), ('saying', 0.079), ('state', 0.079), ('artificially', 0.076), ('verifying', 0.076), ('validate', 0.075), ('hint', 0.075), ('irrelevant', 0.075), ('exercises', 0.075), ('cables', 0.075), ('wanting', 0.073), ('much', 0.072), ('widgets', 0.071)]
simIndex simValue blogId blogTitle
same-blog 1 1.0000004 1566 high scalability-2013-12-18-How to get started with sizing and capacity planning, assuming you don't know the software behavior?
Introduction: Here's a common situation and question from the mechanical-sympathy Google group by Avinash Agrawal on the black art of capacity planning: How to get started with sizing and capacity planning, assuming we don't know the software behavior and its completely new product to deal with? Gil Tene , Vice President of Technology and CTO & Co-Founder, wrote a very understandable and useful answer that is worth highlighting: Start with requirements. I see way too many "capacity planning" exercises that go off spending weeks measuring some irrelevant metrics about a system (like how many widgets per hour can this thing do) without knowing what they actually need it to do. There are two key sets of metrics to state here: the "how much" set and the "how bad" set: In the "How Much" part, you need to establish, based on expected business needs, Numbers for things (like connections, users, streams, transactions or messages per second) that you expect to interact with at the peak t
Introduction: Update 2: Velocity 09: John Allspaw, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr . Insightful talk. Some highlights: Change is good if you can build tools and culture to lower the risk of change. Operations and developers need to become of one mind and respect each other. An automated infrastructure is the one tool you need most. Common source control. One step build. One step deploy. Don't be a pussy, deploy. Always ship trunk. Feature flags - don't branch code, make features runtime configurable in code. Dark launch - release data paths early without UI component. Shared metrics. Adaptive feedback to prioritize important features. IRC for communication for human context. Best solutions occur when dev and op work together and trust each other. Trust is earned by helping each other solve their problems. Look at what new features imply for operations, what can go wrong, and how to recover. Provide knobs and levers to help operations. Devs should have access to production
3 0.1562711 407 high scalability-2008-10-10-The Art of Capacity Planning: Scaling Web Resources
Introduction: Update 3: The book was released! Find it on Amazon at The Art of Capacity Planning . Update 2: Maybe the iPhone can use a little capacity planning? What's Behind the iPhone 3G Glitches : One source says Apple programmed the Infineon chip to demand a more powerful 3G signal than the iPhone really requires. So if too many people try to make a call or go on the Internet in a given area, some of the devices will decide there's insufficient power and switch to the slower network—even if there is enough 3G bandwidth available. Update: To get a taste of what will be served, mySQL DBA has a nice post titled Capacity Planning, Architecture, Scaling, Response time, Throughput . You learn how to figure out when your application will break by building a 3rd order polynomial. Cool stuff! John Allspaw who is the Operations Engineering Manager at Flickr is about to publish a book with O'Reilly. There are not much details so far but it seems interesting and relev
4 0.14225906 381 high scalability-2008-09-08-Guerrilla Capacity Planning and the Law of Universal Scalability
Introduction: In the era of Web 2.0 traditional approaches to capacity planning are often difficult to implement. Guerrilla Capacity Planning facilitates rapid forecasting of capacity requirements based on the opportunistic use of whatever performance data and tools are available. One unique Guerrilla tool is Virtual Load Testing, based on Dr. Gunther's "Universal Law of Computational Scaling", which provides a highly cost-effective method for assessing application scalability. Neil Gunther, M.Sc., Ph.D. is an internationally recognized computer system performance consultant who founded Performance Dynamics Company in 1994. Some reasons why you should understand this law: 1. A lot of people use the term "scalability" without clearly defining it, let alone defining it quantitatively. Computer system scalability must be quantified. If you can't quantify it, you can't guarantee it. The universal law of computational scaling provides that quantification. 2. One the greatest impediments to applying
5 0.11312902 1250 high scalability-2012-05-23-Averages, web performance data, and how your analytics product is lying to you
Introduction: This guest post is written by Josh Fraser , co-founder and CEO of Torbit . Torbit creates tools for measuring, analyzing and optimizing web performance. Â Did you know that 5% of the pageviews on Walmart.com take over 20 seconds to load? Walmart discovered this recently after adding real user measurement (RUM) to analyze their web performance for every single visitor to their site. Walmart used JavaScript to measure their median load time as well as key metrics like their 95th percentile. While 20 seconds is a long time to wait for a website to load, the Walmart story is actually not that uncommon. Remember, this is the worst 5% of their pageviews, not the typical experience. Walmart's median load time was reported at around 4 seconds, meaning half of their visitors loaded Walmart.com faster than 4 seconds and the other half took longer than 4 seconds to load. Using this knowledge, Walmart was prepared to act. By reducing page load times by even one second, Walmart found that
6 0.10764129 788 high scalability-2010-03-04-How MySpace Tested Their Live Site with 1 Million Concurrent Users
7 0.10564473 152 high scalability-2007-11-13-Flickr Architecture
8 0.10056102 1600 high scalability-2014-02-21-Stuff The Internet Says On Scalability For February 21st, 2014
9 0.099724747 920 high scalability-2010-10-15-Troubles with Sharding - What can we learn from the Foursquare Incident?
11 0.099303998 750 high scalability-2009-12-16-Building Super Scalable Systems: Blade Runner Meets Autonomic Computing in the Ambient Cloud
12 0.099167109 1359 high scalability-2012-11-15-Gone Fishin': Justin.Tv's Live Video Broadcasting Architecture
13 0.099158078 1516 high scalability-2013-09-13-Stuff The Internet Says On Scalability For September 13, 2013
14 0.098832123 757 high scalability-2010-01-04-11 Strategies to Rock Your Startup’s Scalability in 2010
15 0.098421745 796 high scalability-2010-03-16-Justin.tv's Live Video Broadcasting Architecture
16 0.097045705 1082 high scalability-2011-07-18-New Relic Architecture - Collecting 20+ Billion Metrics a Day
17 0.095899768 1654 high scalability-2014-06-05-Cloud Architecture Revolution
18 0.094827205 1568 high scalability-2013-12-23-What Happens While Your Brain Sleeps is Surprisingly Like How Computers Stay Sane
19 0.09198463 1240 high scalability-2012-05-07-Startups are Creating a New System of the World for IT
20 0.091236167 313 high scalability-2008-05-02-Friends for Sale Architecture - A 300 Million Page View-Month Facebook RoR App
topicId topicWeight
[(0, 0.179), (1, 0.09), (2, 0.003), (3, 0.001), (4, -0.018), (5, -0.038), (6, -0.008), (7, 0.044), (8, 0.011), (9, -0.057), (10, -0.013), (11, 0.043), (12, 0.005), (13, 0.042), (14, 0.053), (15, -0.025), (16, 0.063), (17, -0.014), (18, -0.036), (19, 0.027), (20, 0.011), (21, -0.027), (22, 0.002), (23, -0.005), (24, -0.059), (25, -0.033), (26, -0.055), (27, 0.015), (28, 0.033), (29, 0.054), (30, -0.006), (31, -0.011), (32, 0.053), (33, 0.029), (34, -0.034), (35, 0.009), (36, -0.013), (37, 0.012), (38, -0.006), (39, -0.004), (40, -0.088), (41, 0.003), (42, 0.073), (43, -0.024), (44, 0.004), (45, 0.026), (46, -0.01), (47, 0.027), (48, 0.002), (49, -0.051)]
simIndex simValue blogId blogTitle
same-blog 1 0.96743077 1566 high scalability-2013-12-18-How to get started with sizing and capacity planning, assuming you don't know the software behavior?
Introduction: Here's a common situation and question from the mechanical-sympathy Google group by Avinash Agrawal on the black art of capacity planning: How to get started with sizing and capacity planning, assuming we don't know the software behavior and its completely new product to deal with? Gil Tene , Vice President of Technology and CTO & Co-Founder, wrote a very understandable and useful answer that is worth highlighting: Start with requirements. I see way too many "capacity planning" exercises that go off spending weeks measuring some irrelevant metrics about a system (like how many widgets per hour can this thing do) without knowing what they actually need it to do. There are two key sets of metrics to state here: the "how much" set and the "how bad" set: In the "How Much" part, you need to establish, based on expected business needs, Numbers for things (like connections, users, streams, transactions or messages per second) that you expect to interact with at the peak t
Introduction: Update 2: Velocity 09: John Allspaw, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr . Insightful talk. Some highlights: Change is good if you can build tools and culture to lower the risk of change. Operations and developers need to become of one mind and respect each other. An automated infrastructure is the one tool you need most. Common source control. One step build. One step deploy. Don't be a pussy, deploy. Always ship trunk. Feature flags - don't branch code, make features runtime configurable in code. Dark launch - release data paths early without UI component. Shared metrics. Adaptive feedback to prioritize important features. IRC for communication for human context. Best solutions occur when dev and op work together and trust each other. Trust is earned by helping each other solve their problems. Look at what new features imply for operations, what can go wrong, and how to recover. Provide knobs and levers to help operations. Devs should have access to production
3 0.76222849 1506 high scalability-2013-08-23-Stuff The Internet Says On Scalability For August 23, 2013
Introduction: Hey, it's HighScalability time: ( Parkour is to terrain as programming is to frameworks ) 5x : AWS vs combined size of other cloud vendors; Every Second on The Internet : Why we need so many servers. Quotable Quotes: @chaliy : Today I learned that I do not understand how #azure scaling works, instance scale does not affect requests/sec I can load. @Lariar : Note how crazy this is. An international launch would have been a huge deal. Now it's just another thing you do. smacktoward : The problem with relying on donations is that people don't make donations. @toddhoffious : Programming is a tool built by logical positivists to solve the problems of idealists and pragmatists. We have a fundamental mismatch here. @etherealmind : Me: "Weird, my phone data isn't working" Them: "They turned the 3G off at the tower because it interferes with the particle accelerator" John Carmack : In computer science, just about t
4 0.74611586 1534 high scalability-2013-10-18-Stuff The Internet Says On Scalability For October 18th, 2013
Introduction: Hey, it's HighScalability time: Test your sense of scale. Is this image of something microscopic or macroscopic? Find out . $3.5 million : Per Episode Cost of Breaking Bad Quotable Quotes: @GammaCounter : "There are 400 billion trees in the Amazon River basin, close to the number of stars in the Milky Way galaxy." @rbranson : Virtualization has near-zero overhead, unless the VM spends most of it's time copying between RAM and network… like memcached or haproxy. @HackerNewsOnion : Programming is 1% inspiration, 99% trying to get your environment working. @aneel : "roundtrips, not bandwidth, is now often the bottleneck for most applications" @jamesurquhart : Not to mention the fact that auto-scaling should happen above IaaS layer. Think multi-cloud. Sheref Mansy : A machine keeps sort of chugging away, without worrying about its environment. But a living system has to. V.D. Veksler : it just came to my attention that Javascri
5 0.74571663 311 high scalability-2008-04-29-Strategy: Sample to Reduce Data Set
Introduction: Update: Arjen links to video Supporting Scalable Online Statistical Processing which shows "rather than doing complete aggregates, use statistical sampling to provide a reasonable estimate (unbiased guess) of the result." When you have a lot of data, sampling allows you to draw conclusions from a much smaller amount of data. That's why sampling is a scalability solution. If you don't have to process all your data to get the information you need then you've made the problem smaller and you'll need fewer resources and you'll get more timely results. Sampling is not useful when you need a complete list that matches a specific criteria. If you need to know the exact set of people who bought a car in the last week then sampling won't help. But, if you want to know many people bought a car then you could take a sample and then create estimate of the full data-set. The difference is you won't really know the exact car count. You'll have a confidence interval saying how confident
6 0.73971236 381 high scalability-2008-09-08-Guerrilla Capacity Planning and the Law of Universal Scalability
7 0.73591214 1225 high scalability-2012-04-09-Why My Slime Mold is Better than Your Hadoop Cluster
8 0.72788906 193 high scalability-2007-12-26-Finding an excellent LAMP developer
9 0.72766137 76 high scalability-2007-08-29-Skype Failed the Boot Scalability Test: Is P2P fundamentally flawed?
10 0.72752202 1503 high scalability-2013-08-19-What can the Amazing Race to the South Pole Teach us About Startups?
11 0.72673273 919 high scalability-2010-10-14-I, Cloud
12 0.72646457 189 high scalability-2007-12-21-Strategy: Limit Result Sets
13 0.72410542 1500 high scalability-2013-08-12-100 Curse Free Lessons from Gordon Ramsay on Building Great Software
14 0.72203523 390 high scalability-2008-09-23-Scaling your cookie recipes
15 0.71561384 1199 high scalability-2012-02-27-Zen and the Art of Scaling - A Koan and Epigram Approach
16 0.71207505 1366 high scalability-2012-12-03-Resiliency is the New Normal - A Deep Look at What It Means and How to Build It
17 0.70809281 1368 high scalability-2012-12-07-Stuff The Internet Says On Scalability For December 7, 2012
18 0.70527261 1172 high scalability-2012-01-10-A Perfect Fifth of Notes on Scalability
19 0.70472205 757 high scalability-2010-01-04-11 Strategies to Rock Your Startup’s Scalability in 2010
20 0.70455515 407 high scalability-2008-10-10-The Art of Capacity Planning: Scaling Web Resources
topicId topicWeight
[(1, 0.149), (2, 0.224), (10, 0.048), (20, 0.184), (26, 0.015), (30, 0.041), (40, 0.013), (61, 0.095), (77, 0.014), (79, 0.094), (94, 0.053)]
simIndex simValue blogId blogTitle
1 0.93604815 23 high scalability-2007-07-24-Major Websites Down: Or Why You Want to Run in Two or More Data Centers.
Introduction: A lot of sites hosted in San Francisco are down because of at least 6 back-to-back power outages power outages. More details at laughingsquid . Sites like SecondLife, Craigstlist, Technorati, Yelp and all Six Apart properties, TypePad, LiveJournal and Vox are all down. The cause was an underground explosion in a transformer vault under a manhole at 560 Mission Street. Flames shot 6 feet out from the manhole cover. Over PG&E; 30,000 customers are without power. What's perplexing is the UPS backup and diesel generators didn't kick in to bring the datacenter back on line. I've never toured that datacenter, but they usually have massive backup systems. It's probably one of those multiple simultaneous failure situations that you hope never happen in real life, but too often do. Or maybe the infrastructure wasn't rolled out completely. Update: the cause was a cascade of failures in a tightly couples system that could never happen :-) Details at Failure Happens: A summary of the power
same-blog 2 0.91857034 1566 high scalability-2013-12-18-How to get started with sizing and capacity planning, assuming you don't know the software behavior?
Introduction: Here's a common situation and question from the mechanical-sympathy Google group by Avinash Agrawal on the black art of capacity planning: How to get started with sizing and capacity planning, assuming we don't know the software behavior and its completely new product to deal with? Gil Tene , Vice President of Technology and CTO & Co-Founder, wrote a very understandable and useful answer that is worth highlighting: Start with requirements. I see way too many "capacity planning" exercises that go off spending weeks measuring some irrelevant metrics about a system (like how many widgets per hour can this thing do) without knowing what they actually need it to do. There are two key sets of metrics to state here: the "how much" set and the "how bad" set: In the "How Much" part, you need to establish, based on expected business needs, Numbers for things (like connections, users, streams, transactions or messages per second) that you expect to interact with at the peak t
3 0.91222882 1615 high scalability-2014-03-19-Strategy: Three Techniques to Survive Traffic Surges by Quickly Scaling Your Site
Introduction: Matthew Might , as a first responder to a surprise traffic surge on his inexpensive linode hosted blog, took emergency steps that you might find useful in a similar situation: Find the bottleneck. Reloading the page in firebug showed the first page took 24 seconds to load and after that everything else loaded quickly. In retrospect this burst meant the site was thread limited as the CPU was idle. Cut image sizes in half with a shell script using ImageMagick's convert. Load time is now 12 seconds. Turn dynamic content into static content using a static index.html file copied using the browser's "view source" feature. Load time is now 6 seconds. Added threads to the Apache configuration file. Load time is now 2 seconds. Crises averted. Because of this quick thinking and quick action the patient survived to serve pages another day. And in fine post-mortem tradition some of the future changes are: Run a cron job to trigger an earlier alert . Email when requ
4 0.88511175 1596 high scalability-2014-02-14-Stuff The Internet Says On Scalability For February 14th, 2014
Introduction: Hey, it's HighScalability time: Climbing the World's Second Tallest Building 5 billion : Number of phone records NSA collects per day; Facebook : 1.23 billion users, 201.6 billion friend connections, 400 billion shared photos, and 7.8 trillion messages sent since the start of 2012. Quotable Quotes: @ShrikanthSS : people repeatedly underestimate the cost of busy waits @mcclure111 : Learning today java․net․URL․equals is a blocking operation that hits the network shook me badly. I don't know if I can trust the world now. @hui_kenneth : @randybias: “3 ways 2 be market leader - be 1st, be best, or be cheapest. #AWS was all 3. Now #googlecloud may be best & is the cheapest.” @thijs : The nice thing about Paper is that we can point out to clients that it took 18 experienced designers and developers two years to build. @neil_conway : My guess is that the split between Spanner and F1 is a great example of Conway's Law. How F
5 0.87566876 825 high scalability-2010-05-10-Sify.com Architecture - A Portal at 3900 Requests Per Second
Introduction: Sify.com is one of the leading portals in India. Samachar.com is owned by the same company and is one of the top content aggregation sites in India, primarily targeting Non-resident Indians from around the world. Ramki Subramanian, an Architect at Sify, has been generous enough to describe the common back-end for both these sites. One of the most notable aspects of their architecture is that Sify does not use a traditional database. They query Solr and then retrieve records from a distributed file system. Over the years many people have argued for file systems over databases. Filesystems can work for key-value lookups, but they don't work for queries, using Solr is a good way around that problem. Another interesting aspect of their system is the use of Drools for intelligent cache invalidation. As we have more and more data duplicated in multiple specialized services, the problem of how to keep them synchronized is a difficult one. A rules engine is a clever approach. Platfo
6 0.87493354 516 high scalability-2009-02-19-Heavy upload server scalability
7 0.87197191 961 high scalability-2010-12-21-SQL + NoSQL = Yes !
8 0.86819118 714 high scalability-2009-10-02-HighScalability has Moved to Squarespace.com!
9 0.86714631 995 high scalability-2011-02-24-Strategy: Eliminate Unnecessary SQL
10 0.85915458 1098 high scalability-2011-08-15-Should any cloud be considered one availability zone? The Amazon experience says yes.
11 0.85439759 370 high scalability-2008-08-18-Forum sort order
12 0.85152715 1609 high scalability-2014-03-11-Building a Social Music Service Using AWS, Scala, Akka, Play, MongoDB, and Elasticsearch
13 0.85024714 1334 high scalability-2012-10-04-Stuff The Internet Says On Scalability For October 5, 2012
14 0.84920132 195 high scalability-2007-12-28-Amazon's EC2: Pay as You Grow Could Cut Your Costs in Half
16 0.8484022 72 high scalability-2007-08-22-Wikimedia architecture
17 0.84815097 1321 high scalability-2012-09-12-Using Varnish for Paywalls: Moving Logic to the Edge
18 0.84769583 1302 high scalability-2012-08-10-Stuff The Internet Says On Scalability For August 10, 2012
19 0.84766161 1171 high scalability-2012-01-09-The Etsy Saga: From Silos to Happy to Billions of Pageviews a Month
20 0.84754395 1499 high scalability-2013-08-09-Stuff The Internet Says On Scalability For August 9, 2013