high_scalability high_scalability-2012 high_scalability-2012-1282 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: Travis Reeder in Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load gives four good ways of handling spikey loads: Have more resources than you'll ever need . Estimate the maximum traffic you'll need and keep that many servers running. Downside is you are paying for capacity you aren't using. Disable features during high loads . Reduce load by disabling features or substituting in lighter weight features. Downside is users to have access to features. Auto scaling . Launch new servers in response to load. Downsides are it's complicated to setup and slow to respond. Random spikes will cause cycling of instances going up and down. Use message queues . Queues soak up work requests during traffic spikes. More servers can be started to process work from the queue. Resources aren't wasted and features are disabled. Downside is increased latency.
sentIndex sentText sentNum sentScore
1 Travis Reeder in Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load gives four good ways of handling spikey loads: Have more resources than you'll ever need . [sent-1, score-0.694]
2 Estimate the maximum traffic you'll need and keep that many servers running. [sent-2, score-0.341]
3 Downside is you are paying for capacity you aren't using. [sent-3, score-0.189]
4 Reduce load by disabling features or substituting in lighter weight features. [sent-5, score-1.026]
5 Downsides are it's complicated to setup and slow to respond. [sent-9, score-0.269]
6 Random spikes will cause cycling of instances going up and down. [sent-10, score-0.585]
7 More servers can be started to process work from the queue. [sent-13, score-0.304]
wordName wordTfidf (topN-words)
[('downside', 0.42), ('cycling', 0.233), ('travis', 0.233), ('spikey', 0.222), ('substituting', 0.222), ('disabling', 0.214), ('soak', 0.202), ('lighter', 0.197), ('wasted', 0.188), ('downsides', 0.185), ('inconsistent', 0.176), ('features', 0.163), ('unknown', 0.163), ('weight', 0.15), ('estimate', 0.15), ('resources', 0.134), ('spikes', 0.129), ('paying', 0.126), ('traffic', 0.121), ('launch', 0.117), ('maximum', 0.114), ('queues', 0.109), ('servers', 0.106), ('loads', 0.106), ('four', 0.101), ('complicated', 0.098), ('random', 0.098), ('setup', 0.095), ('message', 0.094), ('increased', 0.092), ('cause', 0.088), ('handling', 0.082), ('ways', 0.081), ('load', 0.08), ('started', 0.08), ('instances', 0.079), ('ability', 0.077), ('slow', 0.076), ('reduce', 0.076), ('ever', 0.074), ('gives', 0.072), ('response', 0.069), ('work', 0.068), ('capacity', 0.063), ('requests', 0.063), ('going', 0.056), ('latency', 0.056), ('handle', 0.054), ('access', 0.053), ('process', 0.05)]
simIndex simValue blogId blogTitle
same-blog 1 0.99999994 1282 high scalability-2012-07-12-4 Strategies for Punching Down Traffic Spikes
Introduction: Travis Reeder in Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load gives four good ways of handling spikey loads: Have more resources than you'll ever need . Estimate the maximum traffic you'll need and keep that many servers running. Downside is you are paying for capacity you aren't using. Disable features during high loads . Reduce load by disabling features or substituting in lighter weight features. Downside is users to have access to features. Auto scaling . Launch new servers in response to load. Downsides are it's complicated to setup and slow to respond. Random spikes will cause cycling of instances going up and down. Use message queues . Queues soak up work requests during traffic spikes. More servers can be started to process work from the queue. Resources aren't wasted and features are disabled. Downside is increased latency.
2 0.14890954 1325 high scalability-2012-09-19-The 4 Building Blocks of Architecting Systems for Scale
Introduction: If you are looking for an excellent overview of general architecture principles then take a look at Will Larson's Introduction to Architecting Systems for Scale . Based on his experiences at Yahoo! and Digg, Will covers key concepts in some depth. A quick gloss on the building blocks: Load Balancing: Scalability & Redundancy . Horizontal scalability and redundancy are usually achieved via load balancing, the spreading of requests across multiple resources. Smart Clients . The client has a list of hosts and load balances across that list of hosts. Upside is simple for programmers. Downside is it's hard to update and change. Hardware Load Balancers . Targeted at larger companies, this is dedicated load balancing hardware. Upside is performance. Downside is cost and complexity. Software Load Balancers . The recommended approach, it's software that handles load balancing, health checks, etc. Caching . Make better use of resources you already have. Pr
3 0.11405331 533 high scalability-2009-03-11-The Implications of Punctuated Scalabilium for Website Architecture
Introduction: Update: How do you design and handle peak load on the Cloud? by Cloudiquity. Gives a formula to try and predict and plan for peak load and talks about how GigaSpaces XAP, Scalr, RightScale and FreedomOSS can be used to handle peak load within EC2. Theo Schlossnagle, with his usual insight, talks about in Dissecting today's surges how the nature of internet traffic has evolved over time. Traffic now spikes like a heart attack, larger and more quickly than ever from traffic inflow sources like Digg and The New York Times. Theo relates how At least eight times in the past month, we've experienced from 100% to 1000% sudden increases in traffic across many of our clients and those spike can happen as quickly as 60 seconds. To me this sounds a lot like Punctuated equilibrium in evolution, a force that accounts for much creative growth in species... VMs don't spin up in less than 60 seconds so your ability to respond to such massive quick spikes is limited. This as
Introduction: In Don’t panic! Here’s how to quickly scale your mobile apps Mike Maelzer paints a wonderful picture of how Avocado , a mobile app for connecting couples, evolved to handle 30x traffic within a few weeks. If you are just getting started then this is a great example to learn from. What I liked: it's well written, packing a lot of useful information in a little space; it's failure driven, showing the process of incremental change driven by purposeful testing and production experience; it shows awareness of what's important, in their case, user signup; a replica setup was used for testing, a nice cloud benefit. Their Biggest lesson learned is a good one: It would have been great to start the scaling process much earlier. Due to time pressure we had to make compromises –like dropping four of our media resizer boxes. While throwing more hardware at some scaling problems does work, it’s less than ideal. Here's my gloss on the article: Evolution One - Make it Work When just
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
6 0.096449032 1423 high scalability-2013-03-13-Iron.io Moved From Ruby to Go: 28 Servers Cut and Colossal Clusterf**ks Prevented
7 0.093895636 1373 high scalability-2012-12-17-11 Uses For the Humble Presents Queue, er, Message Queue
8 0.092396334 1331 high scalability-2012-10-02-An Epic TripAdvisor Update: Why Not Run on the Cloud? The Grand Experiment.
9 0.086590663 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
10 0.082577333 788 high scalability-2010-03-04-How MySpace Tested Their Live Site with 1 Million Concurrent Users
11 0.080673762 661 high scalability-2009-07-25-Latency is Everywhere and it Costs You Sales - How to Crush it
12 0.076792233 1421 high scalability-2013-03-11-Low Level Scalability Solutions - The Conditioning Collection
13 0.076482028 340 high scalability-2008-06-06-Economies of Non-Scale
14 0.072537839 1207 high scalability-2012-03-12-Google: Taming the Long Latency Tail - When More Machines Equals Worse Results
15 0.070103243 1418 high scalability-2013-03-06-Low Level Scalability Solutions - The Aggregation Collection
16 0.069776773 406 high scalability-2008-10-08-Strategy: Flickr - Do the Essential Work Up-front and Queue the Rest
17 0.068506561 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
18 0.068085141 1266 high scalability-2012-06-18-Google on Latency Tolerant Systems: Making a Predictable Whole Out of Unpredictable Parts
19 0.067943156 1112 high scalability-2011-09-07-What Google App Engine Price Changes Say About the Future of Web Architecture
20 0.067719333 812 high scalability-2010-04-19-Strategy: Order Two Mediums Instead of Two Smalls and the EC2 Buffet
topicId topicWeight
[(0, 0.104), (1, 0.062), (2, -0.012), (3, -0.066), (4, -0.039), (5, -0.051), (6, 0.05), (7, -0.003), (8, -0.044), (9, -0.06), (10, -0.001), (11, 0.016), (12, -0.006), (13, -0.008), (14, -0.025), (15, -0.01), (16, 0.036), (17, 0.009), (18, -0.025), (19, 0.03), (20, -0.0), (21, 0.005), (22, 0.005), (23, -0.05), (24, 0.02), (25, 0.018), (26, -0.007), (27, 0.07), (28, -0.01), (29, -0.042), (30, 0.03), (31, 0.022), (32, 0.007), (33, 0.044), (34, -0.0), (35, -0.016), (36, -0.048), (37, -0.039), (38, -0.043), (39, -0.052), (40, 0.017), (41, -0.024), (42, 0.017), (43, 0.014), (44, -0.073), (45, -0.018), (46, 0.014), (47, -0.006), (48, 0.017), (49, 0.01)]
simIndex simValue blogId blogTitle
same-blog 1 0.9669711 1282 high scalability-2012-07-12-4 Strategies for Punching Down Traffic Spikes
Introduction: Travis Reeder in Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load gives four good ways of handling spikey loads: Have more resources than you'll ever need . Estimate the maximum traffic you'll need and keep that many servers running. Downside is you are paying for capacity you aren't using. Disable features during high loads . Reduce load by disabling features or substituting in lighter weight features. Downside is users to have access to features. Auto scaling . Launch new servers in response to load. Downsides are it's complicated to setup and slow to respond. Random spikes will cause cycling of instances going up and down. Use message queues . Queues soak up work requests during traffic spikes. More servers can be started to process work from the queue. Resources aren't wasted and features are disabled. Downside is increased latency.
2 0.73560959 533 high scalability-2009-03-11-The Implications of Punctuated Scalabilium for Website Architecture
Introduction: Update: How do you design and handle peak load on the Cloud? by Cloudiquity. Gives a formula to try and predict and plan for peak load and talks about how GigaSpaces XAP, Scalr, RightScale and FreedomOSS can be used to handle peak load within EC2. Theo Schlossnagle, with his usual insight, talks about in Dissecting today's surges how the nature of internet traffic has evolved over time. Traffic now spikes like a heart attack, larger and more quickly than ever from traffic inflow sources like Digg and The New York Times. Theo relates how At least eight times in the past month, we've experienced from 100% to 1000% sudden increases in traffic across many of our clients and those spike can happen as quickly as 60 seconds. To me this sounds a lot like Punctuated equilibrium in evolution, a force that accounts for much creative growth in species... VMs don't spin up in less than 60 seconds so your ability to respond to such massive quick spikes is limited. This as
3 0.72255814 772 high scalability-2010-02-05-High Availability Principle : Concurrency Control
Introduction: One important high availability principle is concurrency control. The idea is to allow only that much traffic through to your system which your system can handle successfully. For example: if your system is certified to handle a concurrency of 100 then the 101st request should either timeout, be asked to try later or wait until one of the previous 100 requests finish. The 101st request should not be allowed to negatively impact the experience of the other 100 users. Only the 101st request should be impacted. Read more here...
4 0.69282949 1421 high scalability-2013-03-11-Low Level Scalability Solutions - The Conditioning Collection
Introduction: We talked about 42 Monster Problems That Attack As Loads Increase . And in The Aggregation Collection we talked about the value of prioritizing work and making smart queues as a way of absorbing and not reflecting traffic spikes. Now we move on to our next batch of strategies where the theme is conditioning , which is the idea of shaping and controlling flows of work within your application... Use Resources Proportional To a Fixed Limit This is probably the most important rule for achieving scalability within an application. What it means: Find the resource that has a fixed limit that you know you can support. For example, a guarantee to handle a certain number of objects in memory. So if we always use resources proportional to the number of objects it is likely we can prevent resource exhaustion. Devise ways of tying what you need to do to the individual resources. Some examples: Keep a list of purchase orders with line items over $20 (or whatever). Do not keep
5 0.68437701 1423 high scalability-2013-03-13-Iron.io Moved From Ruby to Go: 28 Servers Cut and Colossal Clusterf**ks Prevented
Introduction: For the last few months I've been programming a system in Go, so I'm always on the lookout for information to feed my confirmation bias. An opportunity popped up when Iron.io wrote about their experience using Go to rewrite IronWorker , their ever busy job execution system, originally coded in Ruby. The result: Dropped from 30 to 2 servers and the second server was used only for redundancy. CPU utilization dropped to less than 5%. Memory usage dropped. Only a "few hundred KB's of memory (on startup) vs our Rails apps which were ~50MB (on startup)". Cascading failures are now a thing of the past. New services running on hundreds of servers are all written in Go. They believe using Go allows them to "build great products, to grow and scale, and attract grade A talent. And I believe it will continue to help us grow for the foreseeable future." Picking a language based on the size of the talent pool is a common recommendation, they've found selecting Go helps them attract
6 0.66436619 1331 high scalability-2012-10-02-An Epic TripAdvisor Update: Why Not Run on the Cloud? The Grand Experiment.
7 0.65752387 275 high scalability-2008-03-14-Problem: Mobbing the Least Used Resource Error
8 0.65630543 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
9 0.65592933 406 high scalability-2008-10-08-Strategy: Flickr - Do the Essential Work Up-front and Queue the Rest
10 0.65213954 1415 high scalability-2013-03-04-7 Life Saving Scalability Defenses Against Load Monster Attacks
12 0.64261955 1622 high scalability-2014-03-31-How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second
13 0.64195883 1438 high scalability-2013-04-10-Check Yourself Before You Wreck Yourself - Avocado's 5 Early Stages of Architecture Evolution
14 0.63891065 249 high scalability-2008-02-16-S3 Failed Because of Authentication Overload
15 0.63797563 1260 high scalability-2012-06-07-Case Study on Scaling PaaS infrastructure
16 0.63180971 1401 high scalability-2013-02-06-Super Bowl Advertisers Ready for the Traffic? Nope..It's Lights Out.
17 0.62923622 1418 high scalability-2013-03-06-Low Level Scalability Solutions - The Aggregation Collection
18 0.62817788 1165 high scalability-2011-12-28-Strategy: Guaranteed Availability Requires Reserving Instances in Specific Zones
19 0.61962527 773 high scalability-2010-02-06-GEO-aware traffic load balancing and caching at CNBC.com
20 0.61811179 573 high scalability-2009-04-16-Serving 250M quotes-day at CNBC.com with aiCache
topicId topicWeight
[(1, 0.065), (2, 0.25), (10, 0.068), (13, 0.333), (79, 0.096), (90, 0.061)]
simIndex simValue blogId blogTitle
same-blog 1 0.85185546 1282 high scalability-2012-07-12-4 Strategies for Punching Down Traffic Spikes
Introduction: Travis Reeder in Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load gives four good ways of handling spikey loads: Have more resources than you'll ever need . Estimate the maximum traffic you'll need and keep that many servers running. Downside is you are paying for capacity you aren't using. Disable features during high loads . Reduce load by disabling features or substituting in lighter weight features. Downside is users to have access to features. Auto scaling . Launch new servers in response to load. Downsides are it's complicated to setup and slow to respond. Random spikes will cause cycling of instances going up and down. Use message queues . Queues soak up work requests during traffic spikes. More servers can be started to process work from the queue. Resources aren't wasted and features are disabled. Downside is increased latency.
2 0.77785188 34 high scalability-2007-07-27-Product: Munin Monitoriting Tool
Introduction: Munin the monitoring tool surveys all your computers and remembers what it saw. It presents all the information in graphs through a web interface. Its emphasis is on plug and play capabilities. After completing a installation a high number of monitoring plugins will be playing with no more effort. Using Munin you can easily monitor the performance of your computers, networks, SANs, applications, weather measurements and whatever comes to mind. It makes it easy to determine "what's different today" when a performance problem crops up. It makes it easy to see how you're doing capacity-wise on any resources.
3 0.73192841 477 high scalability-2008-12-29-100% on Amazon Web Services: Soocial.com - a lesson of porting your service to Amazon
Introduction: Simone Brunozzi, technology evangelist for Amazon Web Services in Europe, describes how Soocial.com was fully ported to Amazon web services. ---------------- This period of the year I decided to dedicate some time to better understand how our customers use AWS, therefore I spent some online time with Stefan Fountain and the nice guys at Soocial.com, a "one address book solution to contact management", and I would like to share with you some details of their IT infrastructure, which now runs 100% on Amazon Web Services! In the last few months, they've been working hard to cope with tens of thousands of users and to get ready to easily scale to millions. To make this possible, they decided to move ALL their architecture to Amazon Web Services. Despite the fact that they were quite happy with their previous hosting provider, Amazon proved to be the way to go. ----------------- Read the rest of the article here .
4 0.72268325 1446 high scalability-2013-04-25-Paper: Making reliable distributed systems in the presence of software errors
Introduction: Joe Armstrong is a co-inventor of Erlang and general all around renaissance software tinkerer as shown by his excellent work on writing a C Compiler and his voluminous work on GitHub . Given the success of Erlang it's probably no surprise that he wrote his thesis on the ground breaking ideas behind Erlang: Making reliable distributed systems in the presence of software errors . Even if you have yet to join the cult of Erlang the principles behind Erlang are universal and well worth exploring for your own designs. Highly recommended. Introduction: How can we program systems which behave in a reasonable manner in the presence of software errors? This is the central question that I hope to answer in this thesis. Large systems will probably always be delivered containing a number of errors in the software, nevertheless such systems are expected to behave in a reasonable manner. To make a reliable system from faulty components places certain requirements on the system. Th
5 0.71418035 1070 high scalability-2011-06-29-Second Hand Seizure : A New Cause of Site Death
Introduction: Like a digital SWAT team that implodes the wrong door on a raid, the FBI seized multiple racks of computers from DigitalOne, these racks host websites from many clients that just happened to be in the same racks as whomever they are investigating. Downed sites include Instapaper, Curbed Network, and Pinboard . With the density of servers these days many 1000s of sites could easily have been effected. Sites like Pinboard were victims by association, they did not inhale. This is an association sites have no control over. On a shared hosting service, you have no control over your fellow VM mates. In a cloud or a managed service, you have no control over which racks your servers are in. So like second hand smoke, you get the disease by random association. There's something inherently unfair about that. A comment by illumin8 shows just how Darth insidious this process can be: A popular method used by hackers is to sign up for a virtual server with a stolen credit card. If t
6 0.71389508 758 high scalability-2010-01-11-Have We Reached the End of Scaling?
7 0.71122056 391 high scalability-2008-09-23-The 7 Stages of Scaling Web Apps
8 0.70151472 112 high scalability-2007-10-04-You Can Now Store All Your Stuff on Your Own Google Like File System
9 0.69321859 1576 high scalability-2014-01-10-Stuff The Internet Says On Scalability For January 10th, 2014
10 0.68139744 664 high scalability-2009-07-29-Strategy: Devirtualize for More Vroom
11 0.63533932 890 high scalability-2010-09-01-Paper: The Case for Determinism in Database Systems
12 0.63343757 673 high scalability-2009-08-07-Strategy: Break Up the Memcache Dog Pile
13 0.63343078 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
14 0.63282096 1431 high scalability-2013-03-29-Stuff The Internet Says On Scalability For March 29, 2013
15 0.62925982 1204 high scalability-2012-03-06-Ask For Forgiveness Programming - Or How We'll Program 1000 Cores
16 0.62468088 417 high scalability-2008-10-15-Outside.in Scales Up with Engine Yard and moving from PHP to Ruby on Rails
17 0.62378407 1456 high scalability-2013-05-13-The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution
18 0.62322158 1266 high scalability-2012-06-18-Google on Latency Tolerant Systems: Making a Predictable Whole Out of Unpredictable Parts
19 0.62274212 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
20 0.62267709 188 high scalability-2007-12-19-How can I learn to scale my project?