high_scalability high_scalability-2008 high_scalability-2008-462 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th
sentIndex sentText sentNum sentScore
1 An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. [sent-1, score-0.098]
2 With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. [sent-2, score-1.095]
3 Some topics: Know your cold paths from your hot paths. [sent-3, score-0.339]
4 Intuition is frequently wrong—be data intensive. [sent-4, score-0.103]
5 Don't use a semaphore where a mutex would suffice. [sent-11, score-0.362]
6 Consider memory retiring to implement per-chain hash-table locks. [sent-12, score-0.293]
7 Consider using nonblocking synchronization routines to monitor contention. [sent-14, score-0.592]
8 When reacquiring locks, consider using generation counts to detect state change. [sent-15, score-0.39]
9 Use wait- and lock-free structures only if you absolutely must. [sent-16, score-0.211]
10 Prepare for the thrill of victory—and the agony of defeat. [sent-17, score-0.221]
11 While I don't agree that code using locks can be made composable, this articles covers a lot of very useful nitty-gritty details that will up your expert rating a couple points. [sent-18, score-1.126]
wordName wordTfidf (topN-words)
[('retiring', 0.221), ('thrill', 0.221), ('wary', 0.221), ('locks', 0.215), ('bonwick', 0.207), ('cantrill', 0.207), ('multiprocessor', 0.207), ('nonblocking', 0.207), ('semaphore', 0.207), ('routines', 0.191), ('composable', 0.175), ('rating', 0.171), ('bryan', 0.171), ('screw', 0.165), ('mutex', 0.155), ('bullet', 0.147), ('threaded', 0.139), ('false', 0.136), ('paths', 0.127), ('debug', 0.125), ('expert', 0.122), ('cold', 0.122), ('synchronization', 0.122), ('counts', 0.119), ('agree', 0.118), ('absolutely', 0.117), ('detect', 0.115), ('aware', 0.112), ('jeff', 0.112), ('covers', 0.112), ('magic', 0.107), ('frequently', 0.103), ('knowing', 0.1), ('break', 0.1), ('couple', 0.1), ('valuable', 0.098), ('write', 0.098), ('topics', 0.098), ('processors', 0.097), ('structures', 0.094), ('hot', 0.09), ('generation', 0.083), ('articles', 0.08), ('code', 0.076), ('points', 0.075), ('consider', 0.073), ('monitor', 0.072), ('implement', 0.072), ('useful', 0.066), ('details', 0.066)]
simIndex simValue blogId blogTitle
same-blog 1 1.0000001 462 high scalability-2008-12-06-Paper: Real-world Concurrency
Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th
2 0.090886623 1541 high scalability-2013-10-31-Paper: Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask
Introduction: Awesome paper on how particular synchronization mechanisms scale on multi-core architectures: Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask . The goal is to pick a locking approach that doesn't degrade as the number of cores increase. Like everything else in life, that doesn't appear to be generically possible: None of the nine locking schemes we consider consistently outperforms any other one, on all target architectures or workloads. Strictly speaking, to seek optimality, a lock algorithm should thus be selected based on the hardware platform and the expected workload . Abstract: This paper presents the most exhaustive study of synchronization to date. We span multiple layers, from hardware cache-coherence protocols up to high-level concurrent software. We do so on different types architectures, from single-socket – uniform and nonuniform – to multi-socket – directory and broadcastbased – many-cores. We draw a set of observations t
3 0.080288433 459 high scalability-2008-12-03-Java World Interview on Scalability and Other Java Scalability Secrets
Introduction: OK, this interview is with me on Java scalability issues. I sound like a bigger idiot than I would like, but I suppose it could have been worse. The Java World folks were very nice and did a good job, so there’s no blame on them :-) The interview went an interesting direction, but there’s more I’d like add and I will do so here. Two major rules regarding Java and scalability have popped out at me: Java – It’s the platform stupid . Java the language isn’t the big win. What is the big win is the ecosystem building up around the JVM, libraries, and toolsets. Java – It’s the community stupid . A lot of creativity is being expended on leveraging the Java platform to meet scalability challenges. The amazing community that has built up around Java is pushing Java to the next level in almost every direction imaginable. The fecundity of the Java ecosystem can most readily be seen with the efforts to tame our multi-core future. There’s a multi-core crisis going in case you haven’t
4 0.07517492 735 high scalability-2009-11-01-Squeeze more performance from Parallelism
Introduction: In many posts, such as: The Future of the Parallelism and its Challenges I mentioned that synchronization the access to the shared resource is the major challenge to write parallel code. The synchronization and coordination take long time from the overall execution time, which reduce the benefits of the parallelism; the synchronization and coordination also reduce the scalability. There are many forms of synchronization and coordination, such as: Create Task object in frameworks such as: Microsoft TPL, Intel TDD, and Parallel Runtime Library. Create and enqueue task objects require synchronization that it’s takes long time especially if we create it into recursive work such as: Quick Sort algorithm. Synchronization the access to shared data. But there are a few techniques to avoid these issues, such as: Shared-Nothing, Actor Model, and Hyper Object (A.K.A. Combinable Object). Simply if we reduce the shared data by re-architect our code this will gives us a huge benefits
5 0.074266151 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier
Introduction: In a paper delivered at HotCloud '12 by a group from CMU and Intel Labs, Saving Cash by Using Less Cache ( slides , pdf ), they show it may be possible to use less DRAM under low load conditions to save on operational costs. There are some issues with this idea, but in a give me more cache era, it could be an interesting source of cost savings for your product. Caching is used to: Reduce load on the database. Reduce latency. Problem: RAM in the cloud is quite expensive. A third of costs can come from the caching tier. Solution: Shrink your cache when the load is lower. Their work shows when the load drops below a certain point you can throw away 50% of your cache while still maintaining performance. A few popular items often account for most of your hits, implying can remove the cache for the long tail. Use two tiers of servers, the Retiring Group, which is the group of servers you want to get rid of. The Primary Group is the group of servers you
6 0.071417369 77 high scalability-2007-08-30-Log Everything All the Time
7 0.069159918 1204 high scalability-2012-03-06-Ask For Forgiveness Programming - Or How We'll Program 1000 Cores
8 0.067145422 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
9 0.061953921 734 high scalability-2009-10-30-Hot Scalabilty Links for October 30 2009
10 0.06143713 920 high scalability-2010-10-15-Troubles with Sharding - What can we learn from the Foursquare Incident?
11 0.058210831 1318 high scalability-2012-09-07-Stuff The Internet Says On Scalability For September 7, 2012
12 0.058152385 914 high scalability-2010-10-04-Paper: An Analysis of Linux Scalability to Many Cores
13 0.055150338 1339 high scalability-2012-10-12-Stuff The Internet Says On Scalability For October 12, 2012
15 0.053021591 1387 high scalability-2013-01-15-More Numbers Every Awesome Programmer Must Know
16 0.052531183 1527 high scalability-2013-10-04-Stuff The Internet Says On Scalability For October 4th, 2013
17 0.051738311 684 high scalability-2009-08-18-Real World Web: Performance & Scalability
18 0.050734509 1045 high scalability-2011-05-20-Stuff The Internet Says On Scalability For May 20, 2011
19 0.050669029 378 high scalability-2008-09-03-Some Facebook Secrets to Better Operations
20 0.050166901 1015 high scalability-2011-04-01-Stuff The Internet Says On Scalability For April 1, 2011
topicId topicWeight
[(0, 0.073), (1, 0.049), (2, -0.0), (3, 0.008), (4, 0.02), (5, 0.034), (6, 0.013), (7, 0.028), (8, -0.034), (9, -0.004), (10, -0.019), (11, -0.017), (12, 0.014), (13, 0.003), (14, -0.012), (15, -0.032), (16, 0.014), (17, -0.002), (18, -0.001), (19, -0.002), (20, 0.014), (21, -0.011), (22, -0.022), (23, 0.016), (24, -0.018), (25, -0.016), (26, 0.031), (27, 0.018), (28, 0.012), (29, 0.038), (30, -0.02), (31, 0.001), (32, 0.005), (33, 0.007), (34, -0.017), (35, 0.006), (36, 0.039), (37, 0.022), (38, 0.037), (39, 0.025), (40, 0.003), (41, 0.022), (42, -0.024), (43, 0.025), (44, -0.005), (45, 0.003), (46, 0.027), (47, 0.038), (48, -0.016), (49, 0.002)]
simIndex simValue blogId blogTitle
same-blog 1 0.91995984 462 high scalability-2008-12-06-Paper: Real-world Concurrency
Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th
2 0.72749674 1462 high scalability-2013-05-22-Strategy: Stop Using Linked-Lists
Introduction: What data structure is more sacred than the link list? If we get rid of it what silly interview questions would we use instead? But not using linked-lists is exactly what Aater Suleman recommends in Should you ever use Linked-Lists? In The Secret To 10 Million Concurrent Connections one of the important strategies is not scribbling data all over memory via pointers because following pointers increases cache misses which reduces performance . And there’s nothing more iconic of pointers than the link list. Here are Aeter's reasons to be anti-linked-list: They reduce the benefit of out-of-order execution. They throw off hardware prefetching. They reduce DRAM and TLB locality. They cannot leverage SIMD. They are harder to send to GPUs. He also demolishes the pros of linked-lists, finding arrays a better option in almost every case. Good discussion in the comment section as not everyone agrees. Patrick Wyatt details how a linked-list threading bug repeated
3 0.68755502 735 high scalability-2009-11-01-Squeeze more performance from Parallelism
Introduction: In many posts, such as: The Future of the Parallelism and its Challenges I mentioned that synchronization the access to the shared resource is the major challenge to write parallel code. The synchronization and coordination take long time from the overall execution time, which reduce the benefits of the parallelism; the synchronization and coordination also reduce the scalability. There are many forms of synchronization and coordination, such as: Create Task object in frameworks such as: Microsoft TPL, Intel TDD, and Parallel Runtime Library. Create and enqueue task objects require synchronization that it’s takes long time especially if we create it into recursive work such as: Quick Sort algorithm. Synchronization the access to shared data. But there are a few techniques to avoid these issues, such as: Shared-Nothing, Actor Model, and Hyper Object (A.K.A. Combinable Object). Simply if we reduce the shared data by re-architect our code this will gives us a huge benefits
4 0.66752887 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
5 0.64558017 510 high scalability-2009-02-09-Paper: Consensus Protocols: Two-Phase Commit
Introduction: Henry Robinson has created an excellent series of articles on consensus protocols. Henry starts with a very useful discussion of what all this talk about consensus really means: The consensus problem is the problem of getting a set of nodes in a distributed system to agree on something - it might be a value, a course of action or a decision. Achieving consensus allows a distributed system to act as a single entity, with every individual node aware of and in agreement with the actions of the whole of the network. In this article Henry tackles Two-Phase Commit, the protocol most databases use to arrive at a consensus for database writes. The article is very well written with lots of pretty and informative pictures. He did a really good job. In conclusion we learn 2PC is very efficient, a minimal number of messages are exchanged and latency is low. The problem is when a co-ordinator fails availability is dramatically reduced. This is why 2PC isn't generally used on highly distributed
6 0.64226043 1621 high scalability-2014-03-28-Stuff The Internet Says On Scalability For March 28th, 2014
8 0.63529849 1537 high scalability-2013-10-25-Stuff The Internet Says On Scalability For October 25th, 2013
9 0.63524997 1239 high scalability-2012-05-04-Stuff The Internet Says On Scalability For May 4, 2012
10 0.63519472 914 high scalability-2010-10-04-Paper: An Analysis of Linux Scalability to Many Cores
11 0.63156283 1204 high scalability-2012-03-06-Ask For Forgiveness Programming - Or How We'll Program 1000 Cores
12 0.63054979 1237 high scalability-2012-05-02-12 Ways to Increase Throughput by 32X and Reduce Latency by 20X
13 0.62747914 1447 high scalability-2013-04-26-Stuff The Internet Says On Scalability For April 26, 2013
14 0.62701327 636 high scalability-2009-06-23-Learn How to Exploit Multiple Cores for Better Performance and Scalability
15 0.61989945 1509 high scalability-2013-08-30-Stuff The Internet Says On Scalability For August 30, 2013
16 0.61664748 1436 high scalability-2013-04-05-Stuff The Internet Says On Scalability For April 5, 2013
17 0.61090326 1246 high scalability-2012-05-16-Big List of 20 Common Bottlenecks
18 0.6017437 826 high scalability-2010-05-12-The Rise of the Virtual Cellular Machines
19 0.59777713 844 high scalability-2010-06-18-Paper: The Declarative Imperative: Experiences and Conjectures in Distributed Logic
20 0.59716082 1297 high scalability-2012-08-03-Stuff The Internet Says On Scalability For August 3, 2012
topicId topicWeight
[(1, 0.034), (2, 0.177), (10, 0.077), (40, 0.087), (61, 0.022), (77, 0.037), (79, 0.07), (87, 0.338), (94, 0.047)]
simIndex simValue blogId blogTitle
1 0.91339886 394 high scalability-2008-09-25-HighScalability.com Rated 16th Best Blog for Development Managers
Introduction: Jurgen Appelo of Noop.nl asked for nominations for top blogs and then performed a sophisticated weighting of their popularity based on page range, trust authority, Alexa rank, Google hits, and number of comments. When all the results poured out of the blender HighScalability was ranked 16th. Not bad! Joel on Software was number one, of course. The next few were: 2) Coding Horror by Jeff Atwood 3) Seth's Blog by Seth Godin and 4) Paul Graham: Essays Paul Graham. All excellent blogs. Very cool.
same-blog 2 0.80495054 462 high scalability-2008-12-06-Paper: Real-world Concurrency
Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th
3 0.71592534 1526 high scalability-2013-10-02-RFC 1925 - The Twelve (Timeless) Networking Truths
Introduction: The Twelve Networking Truths is one of a long series of timeless truths documented in sacred April Fools' RFC s. Though issued in 1996, it's no less true today. It's hard to pick a favorite because they are all good. But if I had to pick, it would be: Some things in life can never be fully appreciated nor understood unless experienced firsthand. As we grow comfortable behind garden walls, clutching gadgets like lifelines and ideologies like shields, empathy is the true social network. Network Working Group R. Callon , Editor Request for Comments: 1925 IOOF Category: Informational 1 April 1996 The Twelve Networking Truths Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract Thi
4 0.71413386 499 high scalability-2009-01-22-Coming soon: better JRockit+Coherence integration
Introduction: At the Oracle Coherence Special Interest Group meeting today in London, Tomas Nilsson, the product manager for JRockit RT and JRockit Mission Control spoke about the future plans for JRockit and especially plans for improved Coherence JRockit integration.
5 0.68147039 1478 high scalability-2013-06-19-Paper: MegaPipe: A New Programming Interface for Scalable Network I-O
Introduction: The paper MegaPipe: A New Programming Interface for Scalable Network I/O ( video , slides ) hits the common theme that if you want to go faster you need a better car design, not just a better driver. So that's why the authors started with a clean-slate and designed a network API from the ground up with support for concurrent I/O, a requirement for achieving high performance while scaling to large numbers of connections per thread, multiple cores, etc. What they created is MegaPipe, "a new network programming API for message-oriented workloads to avoid the performance issues of BSD Socket API." The result: MegaPipe outperforms baseline Linux between 29% (for long connections) and 582% (for short connections) . MegaPipe improves the performance of a modified version of memcached between 15% and 320% . For a workload based on real-world HTTP traces, MegaPipe boosts the throughput of nginx by 75% . What's this most excellent and interesting paper about? Message-oriented netwo
6 0.61203593 1381 high scalability-2013-01-04-Stuff The Internet Says On Scalability For January 4, 2013
7 0.60595399 614 high scalability-2009-06-01-Guess How Many Users it Takes to Kill Your Site?
9 0.55536562 1235 high scalability-2012-04-27-Stuff The Internet Says On Scalability For April 27, 2012
10 0.54199696 683 high scalability-2009-08-18-Hardware Architecture Example (geographical level mapping of servers)
11 0.52418166 353 high scalability-2008-07-20-Strategy: Front S3 with a Caching Proxy
12 0.51952028 330 high scalability-2008-05-27-Should Twitter be an All-You-Can-Eat Buffet or a Vending Machine?
13 0.51857883 1471 high scalability-2013-06-06-Paper: Memory Barriers: a Hardware View for Software Hackers
14 0.51658714 879 high scalability-2010-08-12-Think of Latency as a Pseudo-permanent Network Partition
15 0.51485896 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
16 0.51373065 1419 high scalability-2013-03-07-It's a VM Wasteland - A Near Optimal Packing of VMs to Machines Reduces TCO by 22%
17 0.51285332 1207 high scalability-2012-03-12-Google: Taming the Long Latency Tail - When More Machines Equals Worse Results
18 0.51157737 482 high scalability-2009-01-04-Alternative Memcache Usage: A Highly Scalable, Highly Available, In-Memory Shard Index
19 0.51021063 1429 high scalability-2013-03-25-AppBackplane - A Framework for Supporting Multiple Application Architectures
20 0.50820816 1492 high scalability-2013-07-17-How do you create a 100th Monkey software development culture?