high_scalability high_scalability-2013 high_scalability-2013-1421 knowledge-graph by maker-knowledge-mining
Source: html
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
sentIndex sentText sentNum sentScore
1 So if we always use resources proportional to the number of objects it is likely we can prevent resource exhaustion. [sent-9, score-0.48]
2 a web server redirecting to another server when it is too busy the public telephone system saying all calls are busy which prevents new calls from being accepted Tie Work To Resource Availability Reject work until enough resources become available to accept it. [sent-23, score-0.629]
3 Reference Counting Sharing objects via reference counting can greatly reduce memory usage because only one copy of an object is maintained at any one time. [sent-31, score-0.42]
4 All messages from applications on a node to another node travel over the same link. [sent-62, score-0.52]
5 When your communication layer detects a link is back up or node as back up then reverse the process. [sent-66, score-0.407]
6 This causes more load in the system which inturn causes more retries. [sent-77, score-0.432]
7 Separate Control and Data Planes The idea is that high priority control messages should never block behind data or lower priority control traffic. [sent-91, score-0.625]
8 Structure your system to prevent useless work being done while making sure high priority work gets done when it needs to get done. [sent-93, score-0.588]
9 Chatty programs pump out endless low priority control and data traffic that keeps your system busy doing nothing useful at all. [sent-95, score-0.426]
10 Create a separate network for control and data so control messages always go through. [sent-96, score-0.403]
11 When the newest save the day control message is available current work is stopped so the higher priority item can be processed and it's messages will go out immediately as apposed to sitting back and waiting. [sent-100, score-0.562]
12 Fuel Rod Example In interesting example is moving a fuel rod in a nuclear power plant. [sent-106, score-0.497]
13 Let's take two versions of the move command: move_absolute_from_the_top(inches) move_relative(inches) The absolute version is idempotent because no matter how many times you call it the fuel rod is in the same place. [sent-107, score-0.637]
14 In the relative version if there are command drops and resends the fuel rod will keep moving the number of inches for every application of the command. [sent-108, score-0.649]
15 This means the fuel rod may not be where expected when a command returns. [sent-109, score-0.538]
16 com/RealtimeMantra/CongestionControl : A congestion control system typically monitors various factors like CPU occupancy, link occupancy and messaging delay. [sent-116, score-0.618]
17 The throttling of traffic will reduce the load but it there will be a certain time delay before which the monitored variables like CPU and Link occupancy show downward trend. [sent-119, score-0.538]
18 Congestion control systems are designed to take this into account by spacing out congestion control actions. [sent-120, score-0.431]
19 If the system continues to be overloaded, subsequent congestion control actions can further increase the traffic throttling. [sent-121, score-0.46]
20 If the traffic load is just right, the system maintains current traffic throttling actions. [sent-122, score-0.461]
wordName wordTfidf (topN-words)
[('idempotent', 0.236), ('rod', 0.228), ('fuel', 0.173), ('node', 0.167), ('occupancy', 0.151), ('congestion', 0.145), ('control', 0.143), ('counting', 0.142), ('causes', 0.13), ('work', 0.119), ('senders', 0.118), ('receiver', 0.118), ('messages', 0.117), ('amongst', 0.113), ('throttling', 0.111), ('priority', 0.111), ('inches', 0.109), ('examplein', 0.101), ('accept', 0.1), ('object', 0.099), ('reduce', 0.098), ('request', 0.096), ('example', 0.096), ('retries', 0.096), ('link', 0.096), ('proportional', 0.091), ('traffic', 0.089), ('load', 0.089), ('useless', 0.088), ('calls', 0.086), ('resources', 0.086), ('system', 0.083), ('nfs', 0.082), ('objects', 0.081), ('requests', 0.081), ('resource', 0.079), ('number', 0.075), ('means', 0.073), ('back', 0.072), ('overloaded', 0.071), ('another', 0.069), ('sender', 0.069), ('round', 0.068), ('prevent', 0.068), ('orders', 0.066), ('aggregate', 0.065), ('command', 0.064), ('state', 0.064), ('cpu', 0.063), ('outbound', 0.063)]
simIndex simValue blogId blogTitle
same-blog 1 1.0 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
2 0.32193846 1415 high scalability-2013-03-04-7 Life Saving Scalability Defenses Against Load Monster Attacks
Introduction: We talked about 42 Monster Problems That Attack As Loads Increase . Here are a few ways you can defend yourself, secrets revealed by scaling masters across the ages. Note that these are low level programming level moves, not large architecture type strategies. 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 a list of the line items because the number of items can be much larger than the number of purchase orders. You have kept the resource usage
3 0.32153851 1418 high scalability-2013-03-06-Low Level Scalability Solutions - The Aggregation Collection
Introduction: What good are problems without solutions? In 42 Monster Problems That Attack As Loads Increase we talked about problems. In this first post (OK, there was an earlier post, but I'm doing some reorganizing), we'll cover what I call aggregation strategies. Keep in mind these are low level architecture type suggestions of how to structure the components of your code and how they interact. We're not talking about massive scale-out clusters here, but of what your applications might like like internally, way below the service level interface level. There's a lot more to the world than evented architectures. Aggregation simply means we aren't using stupid queues. Our queues will be smart. We are deeply aware of queues as containers of work that eventually dictate how the entire system performs. As work containers we know intimately what requests and data sit in our queues and we can use that intelligence to our great advantage. Prioritize Work The key idea to it all is an almost mi
4 0.30132183 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
Introduction: For solutions take a look at: 7 Life Saving Scalability Defenses Against Load Monster Attacks . This is a look at all the bad things that can happen to your carefully crafted program as loads increase: all hell breaks lose. Sure, you can scale out or scale up, but you can also choose to program better. Make your system handle larger loads. This saves money because fewer boxes are needed and it will make the entire application more reliable and have better response times. And it can be quite satisfying as a programmer. Large Number Of Objects We usually get into scaling problems when the number of objects gets larger. Clearly resource usage of all types is stressed as the number of objects grow. Continuous Failures Makes An Infinite Event Stream During large network failure scenarios there is never time for the system recover. We are in a continual state of stress. Lots of High Priority Work For example, rerouting is a high priority activity. If there is a large amount
5 0.24545288 1429 high scalability-2013-03-25-AppBackplane - A Framework for Supporting Multiple Application Architectures
Introduction: Hidden in every computer is a hardware backplane for moving signals around. Hidden in every application are ways of moving messages around and giving code CPU time to process them. Unhiding those capabilities and making them first class facilities for the programmer to control is the idea behind AppBackplane. This goes directly against the trend of hiding everything from the programmer and doing it all automagically. Which is great, until it doesn't work. Then it sucks. And the approach of giving the programmer all the power also sucks, until it's tuned to work together and performance is incredible even under increasing loads. Then it's great. These are two different curves going in opposite directions. You need to decide for your application which curve you need to be on. AppBackplane is an example framework supporting the multiple application architectures we talked about in Beyond Threads And Callbacks . It provides a scheduling system that supports continuous and high loa
6 0.22607876 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
7 0.1925426 920 high scalability-2010-10-15-Troubles with Sharding - What can we learn from the Foursquare Incident?
8 0.17517288 1501 high scalability-2013-08-13-In Memoriam: Lavabit Architecture - Creating a Scalable Email Service
11 0.17123002 406 high scalability-2008-10-08-Strategy: Flickr - Do the Essential Work Up-front and Queue the Rest
12 0.16956133 661 high scalability-2009-07-25-Latency is Everywhere and it Costs You Sales - How to Crush it
13 0.16608842 1622 high scalability-2014-03-31-How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second
14 0.16385652 1266 high scalability-2012-06-18-Google on Latency Tolerant Systems: Making a Predictable Whole Out of Unpredictable Parts
15 0.16323878 1142 high scalability-2011-11-14-Using Gossip Protocols for Failure Detection, Monitoring, Messaging and Other Good Things
16 0.16231483 960 high scalability-2010-12-20-Netflix: Use Less Chatty Protocols in the Cloud - Plus 26 Fixes
17 0.15473036 538 high scalability-2009-03-16-Are Cloud Based Memory Architectures the Next Big Thing?
18 0.15267549 761 high scalability-2010-01-17-Applications Become Black Boxes Using Markets to Scale and Control Costs
19 0.14987907 1331 high scalability-2012-10-02-An Epic TripAdvisor Update: Why Not Run on the Cloud? The Grand Experiment.
20 0.14529987 96 high scalability-2007-09-18-Amazon Architecture
topicId topicWeight
[(0, 0.283), (1, 0.16), (2, -0.009), (3, -0.068), (4, -0.044), (5, -0.011), (6, 0.153), (7, 0.085), (8, -0.176), (9, -0.086), (10, -0.0), (11, 0.116), (12, -0.002), (13, -0.061), (14, 0.045), (15, -0.025), (16, 0.023), (17, 0.004), (18, -0.005), (19, 0.035), (20, -0.007), (21, -0.026), (22, 0.046), (23, -0.022), (24, 0.065), (25, 0.012), (26, 0.102), (27, 0.114), (28, 0.05), (29, -0.038), (30, 0.038), (31, -0.029), (32, 0.085), (33, 0.005), (34, 0.064), (35, 0.016), (36, -0.005), (37, -0.06), (38, -0.039), (39, -0.027), (40, 0.03), (41, -0.025), (42, 0.042), (43, 0.037), (44, -0.02), (45, -0.022), (46, -0.024), (47, 0.045), (48, -0.042), (49, 0.019)]
simIndex simValue blogId blogTitle
same-blog 1 0.97305399 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
2 0.92174864 1415 high scalability-2013-03-04-7 Life Saving Scalability Defenses Against Load Monster Attacks
Introduction: We talked about 42 Monster Problems That Attack As Loads Increase . Here are a few ways you can defend yourself, secrets revealed by scaling masters across the ages. Note that these are low level programming level moves, not large architecture type strategies. 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 a list of the line items because the number of items can be much larger than the number of purchase orders. You have kept the resource usage
3 0.9139418 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
Introduction: For solutions take a look at: 7 Life Saving Scalability Defenses Against Load Monster Attacks . This is a look at all the bad things that can happen to your carefully crafted program as loads increase: all hell breaks lose. Sure, you can scale out or scale up, but you can also choose to program better. Make your system handle larger loads. This saves money because fewer boxes are needed and it will make the entire application more reliable and have better response times. And it can be quite satisfying as a programmer. Large Number Of Objects We usually get into scaling problems when the number of objects gets larger. Clearly resource usage of all types is stressed as the number of objects grow. Continuous Failures Makes An Infinite Event Stream During large network failure scenarios there is never time for the system recover. We are in a continual state of stress. Lots of High Priority Work For example, rerouting is a high priority activity. If there is a large amount
4 0.91314811 1418 high scalability-2013-03-06-Low Level Scalability Solutions - The Aggregation Collection
Introduction: What good are problems without solutions? In 42 Monster Problems That Attack As Loads Increase we talked about problems. In this first post (OK, there was an earlier post, but I'm doing some reorganizing), we'll cover what I call aggregation strategies. Keep in mind these are low level architecture type suggestions of how to structure the components of your code and how they interact. We're not talking about massive scale-out clusters here, but of what your applications might like like internally, way below the service level interface level. There's a lot more to the world than evented architectures. Aggregation simply means we aren't using stupid queues. Our queues will be smart. We are deeply aware of queues as containers of work that eventually dictate how the entire system performs. As work containers we know intimately what requests and data sit in our queues and we can use that intelligence to our great advantage. Prioritize Work The key idea to it all is an almost mi
5 0.89071321 1429 high scalability-2013-03-25-AppBackplane - A Framework for Supporting Multiple Application Architectures
Introduction: Hidden in every computer is a hardware backplane for moving signals around. Hidden in every application are ways of moving messages around and giving code CPU time to process them. Unhiding those capabilities and making them first class facilities for the programmer to control is the idea behind AppBackplane. This goes directly against the trend of hiding everything from the programmer and doing it all automagically. Which is great, until it doesn't work. Then it sucks. And the approach of giving the programmer all the power also sucks, until it's tuned to work together and performance is incredible even under increasing loads. Then it's great. These are two different curves going in opposite directions. You need to decide for your application which curve you need to be on. AppBackplane is an example framework supporting the multiple application architectures we talked about in Beyond Threads And Callbacks . It provides a scheduling system that supports continuous and high loa
6 0.87330991 406 high scalability-2008-10-08-Strategy: Flickr - Do the Essential Work Up-front and Queue the Rest
7 0.8533054 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
8 0.82036555 1373 high scalability-2012-12-17-11 Uses For the Humble Presents Queue, er, Message Queue
10 0.80325645 960 high scalability-2010-12-20-Netflix: Use Less Chatty Protocols in the Cloud - Plus 26 Fixes
11 0.80116081 772 high scalability-2010-02-05-High Availability Principle : Concurrency Control
12 0.79338098 1591 high scalability-2014-02-05-Little’s Law, Scalability and Fault Tolerance: The OS is your bottleneck. What you can do?
13 0.79302496 205 high scalability-2008-01-10-Letting Clients Know What's Changed: Push Me or Pull Me?
14 0.78288567 1001 high scalability-2011-03-09-Google and Netflix Strategy: Use Partial Responses to Reduce Request Sizes
15 0.77076501 1454 high scalability-2013-05-08-Typesafe Interview: Scala + Akka is an IaaS for Your Process Architecture
16 0.76888222 350 high scalability-2008-07-15-ZooKeeper - A Reliable, Scalable Distributed Coordination System
17 0.75407386 318 high scalability-2008-05-14-New Facebook Chat Feature Scales to 70 Million Users Using Erlang
18 0.74687749 699 high scalability-2009-09-10-How to handle so many socket connection
19 0.74509138 1266 high scalability-2012-06-18-Google on Latency Tolerant Systems: Making a Predictable Whole Out of Unpredictable Parts
20 0.74452883 981 high scalability-2011-02-01-Google Strategy: Tree Distribution of Requests and Responses
topicId topicWeight
[(1, 0.09), (2, 0.278), (10, 0.07), (15, 0.105), (30, 0.03), (37, 0.022), (40, 0.02), (47, 0.014), (61, 0.073), (77, 0.017), (79, 0.098), (85, 0.024), (94, 0.067), (96, 0.013)]
simIndex simValue blogId blogTitle
1 0.97173238 1455 high scalability-2013-05-10-Stuff The Internet Says On Scalability For May 10, 2013
Introduction: Hey, it's HighScalability time: ( In Thailand, they figured out how to solve the age-old queuing problem! ) Nanoscale : Plants IM Using Nanoscale Sound Waves; 100 petabytes : CERN data storage Quotable Quotes: Geoff Arnold : Arguably all interesting advances in computer science and software engineering occur when a resource that was previously scarce or expensive becomes cheap and plentiful. @jamesurquhart : "Complexity is a characteristic of the system, not of the parts in it." -Dekker @louisnorthmore : Scaling down - now that's scalability! @peakscale : Where distributed systems people retire to forget the madness: http://en.wikipedia.org/wiki/Antipaxos @dozba : "The Linux Game Database" ... Well, at least they will never have scaling problems. Michael Widenius : There is no reason at all to use MySQL @steveloughran : Whenever someone says "unlimited scalability", ask if that exceeds the ber
Introduction: Ever wonder what powers Google's world spirit sensing Zeitgeist service ? No, it's not a homunculus of Georg Wilhelm Friedrich Hegel sitting in each browser. It's actually a stream processing (think streaming MapReduce on steroids) system called MillWheel, described in this very well written paper: MillWheel: Fault-Tolerant Stream Processing at Internet Scale . MillWheel isn't just used for Zeitgeist at Google, it's also used for streaming joins for a variety of Ads customers, generalized anomaly-detection service, and network switch and cluster health monitoring. Abstract: MillWheel is a framework for building low-latency data-processing applications that is widely used at Google. Users specify a directed computation graph and application code for individual nodes, and the system manages persistent state and the continuous flow of records, all within the envelope of the framework’s fault-tolerance guarantees. This paper describes MillWheel’s programming model as well as it
same-blog 3 0.96234256 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
4 0.95849186 923 high scalability-2010-10-21-Machine VM + Cloud API - Rewriting the Cloud from Scratch
Introduction: Write a little "Hello World" program these days and it runs inside a bewildering Russian Doll of nested environments, each layer adding its own special performance and complexity tax. First, a language executes in its own environment of data structure libraries, memory management, and so on. That, more often than not, will run inside a language VM like the JVM, CLR, or V8. The language VM will in-turn run inside a process that runs inside an OS. An application will run in one or more threads inside a process. And the whole thing will run inside a machine sharing VM layer like Xen. And across all of that are frameworks for monitoring, elasticity, storage, and so on. That's a lot of overhead for a such a little program. What if we could remove all these taxes and run directly on the new bare metal, which some consider to be a combination of M achine VM + Cloud API ? That's exactly what a system called Mirage , described in the paper Turning down the LAMP: Software Specialisation for
5 0.95225555 1297 high scalability-2012-08-03-Stuff The Internet Says On Scalability For August 3, 2012
Introduction: It's HighScalability Time: Quotable Quotes: Ross Tur : the tricks you learned to make things big are not the same tricks you can apply to make things infinite. @gclaramunt : Son, I'm getting old, but let me tell you a secret: programming is hard, and high scalability and concurrent programming... frigging hard! @Carnage4Life : At Apple the iOS team didn't see iPhone hardware or hardware team see OS until it shipped @adrianco : #ebspio caps iops but latency variance is much lower than EBS @bernardgolden : RT @peakscale: A culture of automation is 10x more important than deployment/test/monkey thing you'd like to discuss < devops calling @JayCollier : 50 years ago, school standardization was needed for scale. Now, scalability and flexibility (variability) can coexist. #FOL2012 @adrianco : Compared to vanilla EBS many times better for random reads. Bandwidth limits both for sequential and writes. #ebspio @SQLPerfTips : More hardw
6 0.94277668 221 high scalability-2008-01-24-Mailinator Architecture
7 0.9422335 1237 high scalability-2012-05-02-12 Ways to Increase Throughput by 32X and Reduce Latency by 20X
8 0.94169998 812 high scalability-2010-04-19-Strategy: Order Two Mediums Instead of Two Smalls and the EC2 Buffet
9 0.94146085 1418 high scalability-2013-03-06-Low Level Scalability Solutions - The Aggregation Collection
10 0.93997222 1207 high scalability-2012-03-12-Google: Taming the Long Latency Tail - When More Machines Equals Worse Results
11 0.93825811 362 high scalability-2008-08-11-Distributed Computing & Google Infrastructure
12 0.93800151 1010 high scalability-2011-03-24-Strategy: Disk Backup for Speed, Tape Backup to Save Your Bacon, Just Ask Google
13 0.93764615 960 high scalability-2010-12-20-Netflix: Use Less Chatty Protocols in the Cloud - Plus 26 Fixes
14 0.93703192 661 high scalability-2009-07-25-Latency is Everywhere and it Costs You Sales - How to Crush it
15 0.9365114 1204 high scalability-2012-03-06-Ask For Forgiveness Programming - Or How We'll Program 1000 Cores
16 0.93567294 533 high scalability-2009-03-11-The Implications of Punctuated Scalabilium for Website Architecture
17 0.93521774 1475 high scalability-2013-06-13-Busting 4 Modern Hardware Myths - Are Memory, HDDs, and SSDs Really Random Access?
18 0.93456846 1509 high scalability-2013-08-30-Stuff The Internet Says On Scalability For August 30, 2013
20 0.93447948 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase