high_scalability high_scalability-2014 high_scalability-2014-1652 knowledge-graph by maker-knowledge-mining
Source: html
Introduction: Arvid Norberg on the libtorrent blog has put together an excellent list of principles of high performance programs , obviously derived from hard won experience programming on bittorrent: Two fundamental causes of performance problems: Memory Latency . A big performance problem on modern computers is the latency of SDRAM. The CPU waits idle for a read from memory to come back. Context Switching . When a CPU switches context "the memory it will access is most likely unrelated to the memory the previous context was accessing. This often results in significant eviction of the previous cache, and requires the switched-to context to load much of its data from RAM, which is slow." Rules to help balance the forces of evil: Batch work . Avoid context switching by batching work. For example, there are vector versions of system calls like writev() and readv() that operate on more than one item per call. An implication is that you want to merge as many writes as possible.
sentIndex sentText sentNum sentScore
1 Arvid Norberg on the libtorrent blog has put together an excellent list of principles of high performance programs , obviously derived from hard won experience programming on bittorrent: Two fundamental causes of performance problems: Memory Latency . [sent-1, score-0.459]
2 The CPU waits idle for a read from memory to come back. [sent-3, score-0.493]
3 When a CPU switches context "the memory it will access is most likely unrelated to the memory the previous context was accessing. [sent-5, score-1.397]
4 This often results in significant eviction of the previous cache, and requires the switched-to context to load much of its data from RAM, which is slow. [sent-6, score-0.556]
5 " Rules to help balance the forces of evil: Batch work . [sent-7, score-0.088]
6 For example, there are vector versions of system calls like writev() and readv() that operate on more than one item per call. [sent-9, score-0.359]
7 An implication is that you want to merge as many writes as possible. [sent-10, score-0.197]
8 Waking a thread up every 100ms or when 100 jobs are queued, or using fixed size buffers, doesn't adapt to changing circumstances. [sent-13, score-0.461]
9 Organically adapt your job-batching sizes to the granularity of the scheduler and the time it takes for your thread to wake up. [sent-16, score-0.968]
10 Adapt receive buffer sizes for sockets , while at the same time avoiding to copy memory out of the kernel. [sent-17, score-0.79]
11 Always complete all work queued up for a thread before going back to sleep. [sent-18, score-0.339]
12 Only signal a worker thread to wake up when the number of jobs on its queue go from 0 to > 0. [sent-19, score-0.923]
13 Any other signal is redundant and a waste of time. [sent-20, score-0.299]
14 There are also many other interesting articles on the site: memory cache optimizations , swarm connectivity , asynchronous disk I/O . [sent-22, score-0.34]
wordName wordTfidf (topN-words)
[('memory', 0.263), ('wake', 0.252), ('context', 0.251), ('thread', 0.234), ('buffers', 0.209), ('signal', 0.209), ('bloghas', 0.169), ('sizes', 0.167), ('eviction', 0.159), ('waking', 0.151), ('previous', 0.146), ('unrelated', 0.137), ('waits', 0.128), ('bittorrent', 0.126), ('jobs', 0.126), ('theoriginal', 0.124), ('avoid', 0.117), ('granularity', 0.117), ('batching', 0.112), ('derived', 0.109), ('copying', 0.107), ('sockets', 0.107), ('implication', 0.107), ('vector', 0.106), ('queued', 0.105), ('worker', 0.102), ('idle', 0.102), ('adapt', 0.101), ('evil', 0.099), ('won', 0.098), ('scheduler', 0.097), ('item', 0.095), ('merge', 0.09), ('waste', 0.09), ('switching', 0.089), ('predictable', 0.089), ('buffer', 0.088), ('forces', 0.088), ('switches', 0.086), ('fundamental', 0.086), ('obviously', 0.086), ('avoiding', 0.086), ('magic', 0.082), ('causes', 0.08), ('versions', 0.08), ('receive', 0.079), ('cpu', 0.078), ('operate', 0.078), ('cache', 0.077), ('rules', 0.076)]
simIndex simValue blogId blogTitle
same-blog 1 0.99999988 1652 high scalability-2014-05-21-9 Principles of High Performance Programs
Introduction: Arvid Norberg on the libtorrent blog has put together an excellent list of principles of high performance programs , obviously derived from hard won experience programming on bittorrent: Two fundamental causes of performance problems: Memory Latency . A big performance problem on modern computers is the latency of SDRAM. The CPU waits idle for a read from memory to come back. Context Switching . When a CPU switches context "the memory it will access is most likely unrelated to the memory the previous context was accessing. This often results in significant eviction of the previous cache, and requires the switched-to context to load much of its data from RAM, which is slow." Rules to help balance the forces of evil: Batch work . Avoid context switching by batching work. For example, there are vector versions of system calls like writev() and readv() that operate on more than one item per call. An implication is that you want to merge as many writes as possible.
Introduction: Most every programmer who gets sucked into deep performance analysis for long running processes eventually realizes memory allocation is the heart of evil at the center of many of their problems. So you replace malloc with something less worse. Or you tune your garbage collector like a fine ukulele. But there's a smarter approach brought to you from the folks at RAMCloud , a Stanford University production, which is a large scale, distributed, in-memory key-value database. What they've found is that typical memory management approaches don't work and using a log structured approach yields massive benefits: Performance measurements of log-structured memory in RAMCloud show that it enables high client through- put at 80-90% memory utilization, even with artificially stressful workloads. In the most stressful workload, a single RAMCloud server can support 270,000-410,000 durable 100-byte writes per second at 90% memory utilization. The two-level approach to cleaning improves perform
3 0.13230176 538 high scalability-2009-03-16-Are Cloud Based Memory Architectures the Next Big Thing?
Introduction: We are on the edge of two potent technological changes: Clouds and Memory Based Architectures. This evolution will rip open a chasm where new players can enter and prosper. Google is the master of disk. You can't beat them at a game they perfected. Disk based databases like SimpleDB and BigTable are complicated beasts, typical last gasp products of any aging technology before a change. The next era is the age of Memory and Cloud which will allow for new players to succeed. The tipping point will be soon. Let's take a short trip down web architecture lane: It's 1993: Yahoo runs on FreeBSD, Apache, Perl scripts and a SQL database It's 1995: Scale-up the database. It's 1998: LAMP It's 1999: Stateless + Load Balanced + Database + SAN It's 2001: In-memory data-grid. It's 2003: Add a caching layer. It's 2004: Add scale-out and partitioning. It's 2005: Add asynchronous job scheduling and maybe a distributed file system. It's 2007: Move it all into the cloud. It's 2008: C
4 0.13174368 1187 high scalability-2012-02-03-Stuff The Internet Says On Scalability For February 3, 2012
Introduction: I'm only here for the HighScalability: 762 billion : objects stored on S3; $1B/Quarter : Google spend on servers; 100 Petabytes : Storage for Facebook's photos and videos. Quotable Quotes: @knorth2 : #IPO filing says #Facebook is "dependent on our ability to maintain and scale our technical infrastructure" @debuggist : Scalability trumps politics. @cagedether : Hype of #Hadoop is driving pressure on people to keep everything @nanreh : My MongoDB t shirt has never helped me get laid. This is typical with #nosql databases. @lusis : I kenna do it, Capt'n. IO is pegged, disk is saturated…I lost 3 good young men when the cache blew up! Kenton Varda : Jeff Dean puts his pants on one leg at a time, but if he had more than two legs, you'd see that his approach is actually O(log n) One upon a time manufacturing located near rivers for power. Likewise software will be located next to storage, CPU, and analytics resources in a small cartel of clouds. That's the c
5 0.13022925 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons
Introduction: There's not a lot of talk about application architectures at the process level. You have your threads, pools of threads, and you have your callback models. That's about it. Languages/frameworks making a virtue out of simple models, like Go and Erlang, do so at the price of control. It's difficult to make a low latency well conditioned application when a power full tool, like work scheduling, is taken out of the hands of the programmer. But that's not all there is my friend. We'll dive into different ways an application can be composed across threads of control. Your favorite language may not give you access to all the capabilities we are going to talk about, but lately there has been a sort of revival in considering performance important, especially for controlling latency variance , so I think it's time to talk about these kind of issues. When it was do everything in the thread of a web server thread pool none of these issues really mattered. But now that developers are creating
6 0.12517007 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
8 0.11980116 1640 high scalability-2014-04-30-10 Tips for Optimizing NGINX and PHP-fpm for High Traffic Sites
9 0.11823093 661 high scalability-2009-07-25-Latency is Everywhere and it Costs You Sales - How to Crush it
11 0.11264343 1471 high scalability-2013-06-06-Paper: Memory Barriers: a Hardware View for Software Hackers
12 0.11095601 317 high scalability-2008-05-10-Hitting 300 SimbleDB Requests Per Second on a Small EC2 Instance
13 0.1086305 1118 high scalability-2011-09-19-Big Iron Returns with BigMemory
14 0.10745703 1246 high scalability-2012-05-16-Big List of 20 Common Bottlenecks
15 0.10718036 920 high scalability-2010-10-15-Troubles with Sharding - What can we learn from the Foursquare Incident?
16 0.10694204 1319 high scalability-2012-09-10-Russ’ 10 Ingredient Recipe for Making 1 Million TPS on $5K Hardware
17 0.10531978 92 high scalability-2007-09-15-The Role of Memory within Web 2.0 Architectures and Deployments
18 0.10487144 1551 high scalability-2013-11-20-How Twitter Improved JVM Performance by Reducing GC and Faster Memory Allocation
19 0.10447093 1003 high scalability-2011-03-14-6 Lessons from Dropbox - One Million Files Saved Every 15 minutes
20 0.10244071 1038 high scalability-2011-05-11-Troubleshooting response time problems – why you cannot trust your system metrics
topicId topicWeight
[(0, 0.146), (1, 0.098), (2, -0.031), (3, -0.015), (4, -0.029), (5, 0.052), (6, 0.086), (7, 0.102), (8, -0.12), (9, -0.051), (10, -0.003), (11, -0.06), (12, 0.039), (13, 0.028), (14, -0.079), (15, -0.082), (16, 0.005), (17, -0.019), (18, -0.001), (19, 0.021), (20, -0.03), (21, -0.024), (22, 0.024), (23, 0.089), (24, -0.001), (25, -0.043), (26, 0.045), (27, -0.006), (28, 0.009), (29, -0.019), (30, 0.07), (31, 0.011), (32, 0.038), (33, -0.025), (34, 0.015), (35, 0.02), (36, -0.006), (37, 0.032), (38, -0.016), (39, 0.045), (40, 0.069), (41, 0.026), (42, 0.02), (43, 0.022), (44, 0.024), (45, -0.006), (46, -0.015), (47, -0.05), (48, 0.025), (49, -0.002)]
simIndex simValue blogId blogTitle
same-blog 1 0.97975355 1652 high scalability-2014-05-21-9 Principles of High Performance Programs
Introduction: Arvid Norberg on the libtorrent blog has put together an excellent list of principles of high performance programs , obviously derived from hard won experience programming on bittorrent: Two fundamental causes of performance problems: Memory Latency . A big performance problem on modern computers is the latency of SDRAM. The CPU waits idle for a read from memory to come back. Context Switching . When a CPU switches context "the memory it will access is most likely unrelated to the memory the previous context was accessing. This often results in significant eviction of the previous cache, and requires the switched-to context to load much of its data from RAM, which is slow." Rules to help balance the forces of evil: Batch work . Avoid context switching by batching work. For example, there are vector versions of system calls like writev() and readv() that operate on more than one item per call. An implication is that you want to merge as many writes as possible.
2 0.88187259 1471 high scalability-2013-06-06-Paper: Memory Barriers: a Hardware View for Software Hackers
Introduction: It's not often you get so enthusiastic a recommendation for a paper as Sergio Bossa gives Memory Barriers: a Hardware View for Software Hackers : If you only want to read one piece about CPUs architecture, cache coherency and memory barriers, make it this one. It is a clear and well written article. It even has a quiz. What's it about? So what possessed CPU designers to cause them to inflict memory barriers on poor unsuspecting SMP software designers? In short, because reordering memory references allows much better performance, and so memory barriers are needed to force ordering in things like synchronization primitives whose correct operation depends on ordered memory references. Getting a more detailed answer to this question requires a good understanding of how CPU caches work, and especially what is required to make caches really work well. The following sections: present the structure of a cache, describe how cache-coherency protocols ensure that CPUs agree on t
3 0.79925776 1246 high scalability-2012-05-16-Big List of 20 Common Bottlenecks
Introduction: In Zen And The Art Of Scaling - A Koan And Epigram Approach , Russell Sullivan offered an interesting conjecture: there are 20 classic bottlenecks. This sounds suspiciously like the idea that there only 20 basic story plots . And depending on how you chunkify things, it may be true, but in practice we all know bottlenecks come in infinite flavors, all tasting of sour and ash. One day Aurelien Broszniowski from Terracotta emailed me his list of bottlenecks, we cc’ed Russell in on the conversation, he gave me his list, I have a list, and here’s the resulting stone soup. Russell said this is his “I wish I knew when I was younger" list and I think that’s an enriching way to look at it. The more experience you have, the more different types of projects you tackle, the more lessons you’ll be able add to a list like this. So when you read this list, and when you make your own, you are stepping through years of accumulated experience and more than a little frustration, but in ea
4 0.78974903 1582 high scalability-2014-01-20-8 Ways Stardog Made its Database Insanely Scalable
Introduction: Stardog makes a commercial graph database that is a great example of what can be accomplished with a scale-up strategy on BigIron. In a recent article StarDog described how they made their new 2.1 release insanely scalable, improving query scalability by about 3 orders of magnitude and it can now handle 50 billion triples on a $10,000 server with 32 cores and 256 GB RAM. It can also load 20B datasets at 300,000 triples per second. What did they do that you can also do? Avoid locks by using non-blocking algorithms and data structures . For example, moving from BitSet to ConcurrentLinkedQueue. Use ThreadLocal aggressively to reduce thread contention and avoid synchronization . Batch LRU evictions in a single thread . Triggered by several LRU caches becoming problematic when evictions were being swamped by additions. Downside is batching increases memory pressure and GC times. Move to SHA1 for hashing URIs, bnodes, and literal values . Making hash collisions nearly imp
5 0.77175367 1237 high scalability-2012-05-02-12 Ways to Increase Throughput by 32X and Reduce Latency by 20X
Introduction: Martin Thompson , a high-performance technology geek, has written an awesome post, Fun with my-Channels Nirvana and Azul Zing . In it Martin shows the process and techniques he used to take an existing messaging product, written in Java, and increase throughput by 32X and reduce latency by 20X. The article is very well written with lots of interesting details that make it well worth reading. The Techniques The techniques are a good mix of Java independent approaches, things you may have heard of before, things you probably haven’t heard of before, and Java specific heroics. The obvious winning technique is to create a lock free flow through the system. This shouldn’t be surprising as Martin teaches what sounds like a really good lock-free concurrency course . Do not use locks in the main transaction flow because they cause context switches, and therefore latency and unpredictable jitter. Never have more threads that need to run than you have cores availab
7 0.76710117 1536 high scalability-2013-10-23-Strategy: Use Linux Taskset to Pin Processes or Let the OS Schedule It?
8 0.75264651 1218 high scalability-2012-03-29-Strategy: Exploit Processor Affinity for High and Predictable Performance
9 0.74526787 1314 high scalability-2012-08-30-Dramatically Improving Performance by Debugging Brutally Complex Prolems
10 0.73371321 1475 high scalability-2013-06-13-Busting 4 Modern Hardware Myths - Are Memory, HDDs, and SSDs Really Random Access?
11 0.73290086 1003 high scalability-2011-03-14-6 Lessons from Dropbox - One Million Files Saved Every 15 minutes
12 0.73169315 1467 high scalability-2013-05-30-Google Finds NUMA Up to 20% Slower for Gmail and Websearch
13 0.72385842 1387 high scalability-2013-01-15-More Numbers Every Awesome Programmer Must Know
14 0.71989715 1319 high scalability-2012-09-10-Russ’ 10 Ingredient Recipe for Making 1 Million TPS on $5K Hardware
15 0.70587069 505 high scalability-2009-02-01-More Chips Means Less Salsa
16 0.69441688 1038 high scalability-2011-05-11-Troubleshooting response time problems – why you cannot trust your system metrics
17 0.6940878 1413 high scalability-2013-02-27-42 Monster Problems that Attack as Loads Increase
18 0.69226921 92 high scalability-2007-09-15-The Role of Memory within Web 2.0 Architectures and Deployments
19 0.68397462 1462 high scalability-2013-05-22-Strategy: Stop Using Linked-Lists
20 0.67957872 1456 high scalability-2013-05-13-The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution
topicId topicWeight
[(1, 0.151), (2, 0.226), (10, 0.014), (22, 0.195), (30, 0.076), (40, 0.041), (61, 0.051), (77, 0.039), (79, 0.089), (85, 0.027)]
simIndex simValue blogId blogTitle
Introduction: The story of driving the golden spike to symbolize the completion of the transcontinental railroad is famous in the US. What is not so well known is the story of how it also foreshadowed changes to come as an early version of both the Internet and the Internet of Things. But that was 1869, how can that possibly be? Telegraph as Internet First, let's establish the telegraph and cable systems was an early version of an Internet. As railroad tracks were being laid a transcontental telegraph system was also being constructed. Telegraph lines were installed parallel to the tracks making instant communication available across the continent, faster than any horse could ride. With the transalantic cable system information could quickly span continents in minutes: The miles of American telegraph grew from 40 in 1846 to 12,000 in 1850 to 23,000 in 1852. In Europe it increased from 2,000 in 1849 to 110,000 in 1869. The cost of sending 10 words was $1.55 in 1850, $1 in 1870, 40
2 0.90897 491 high scalability-2009-01-13-Product: Gearman - Open Source Message Queuing System
Introduction: Update: New Gearman Server & Library in C, MySQL UDFs . Gearman is an open source message queuing system that makes it easy to do distributed job processing using multiple languages. With Gearman you: farm out work to other machines, dispatching function calls to machines that are better suited to do work, to do work in parallel, to load balance lots of function calls, to call functions between languages, spread CPU usage around your network . Gearman is used by companies like LiveJournal, Yahoo!, and Digg. Digg, for example, runs 300,000 jobs a day through Gearman without any issues. Most large sites use something similar. Why would anyone ever even need a message queuing system? Message queuing is a handy way to move work off your web servers (like image manipulation), to generate thousands of documents in the background, to run the multiple requests in parallel needed to build a web page, or to perform tasks that can comfortably be run in the background and not part
3 0.90401781 179 high scalability-2007-12-10-Future of EJB3 !! ??
Introduction: What i s the future of EJB3 i n the i ndustry , g i ven the current trends ? There are a l ot of arguments regard i ng EJB3 be i ng heavy we i ghted ..... A l so, what cou l d be the a l ternat i ves of EJB3 ? How about the sca l abi l ity, pers i stence, performance and other factors ?
same-blog 4 0.88383794 1652 high scalability-2014-05-21-9 Principles of High Performance Programs
Introduction: Arvid Norberg on the libtorrent blog has put together an excellent list of principles of high performance programs , obviously derived from hard won experience programming on bittorrent: Two fundamental causes of performance problems: Memory Latency . A big performance problem on modern computers is the latency of SDRAM. The CPU waits idle for a read from memory to come back. Context Switching . When a CPU switches context "the memory it will access is most likely unrelated to the memory the previous context was accessing. This often results in significant eviction of the previous cache, and requires the switched-to context to load much of its data from RAM, which is slow." Rules to help balance the forces of evil: Batch work . Avoid context switching by batching work. For example, there are vector versions of system calls like writev() and readv() that operate on more than one item per call. An implication is that you want to merge as many writes as possible.
5 0.87950391 1621 high scalability-2014-03-28-Stuff The Internet Says On Scalability For March 28th, 2014
Introduction: Hey, it's HighScalability time: Looks like a multiverse , if you can keep it. Quotable Quotes: @abt_programming : "I am a Unix Creationist. I believe the world was created on January 1, 1970 and as prophesized, will end on January 19, 2038" - @teropa @demisbellot : Cloud prices are hitting attractive price points, one more 40-50% drop and there'd be little reason to go it alone. @scott4arrows : Dentist "Do you floss regularly?" Me "Do you back up your computer data regularly?" @avestal : "I Kickstarted the Oculus Rift, what do I get?" You get a lesson in how capitalism works. @mtabini : “$20 charger that cost $2 to make.” Not pictured here: the $14 you pay for the 10,000 charger iterations that never made it to production. @strlen : "I built the original assembler in JS, because it's what I prefer to use when I need to get down to bare metal." - Adm. Grace Hopper tedchs : I'd like to propose a new rule for Hacker News: only if you have b
6 0.86540431 1645 high scalability-2014-05-09-Stuff The Internet Says On Scalability For May 9th, 2014
7 0.86489213 774 high scalability-2010-02-08-How FarmVille Scales to Harvest 75 Million Players a Month
8 0.86355144 1090 high scalability-2011-08-01-Peecho Architecture - scalability on a shoestring
9 0.85266131 1543 high scalability-2013-11-05-10 Things You Should Know About AWS
10 0.83959866 1508 high scalability-2013-08-28-Sean Hull's 20 Biggest Bottlenecks that Reduce and Slow Down Scalability
11 0.82586509 621 high scalability-2009-06-06-Graph server
12 0.82571232 1143 high scalability-2011-11-16-Google+ Infrastructure Update - the JavaScript Story
13 0.82389677 301 high scalability-2008-04-08-Google AppEngine - A First Look
15 0.81964153 573 high scalability-2009-04-16-Serving 250M quotes-day at CNBC.com with aiCache
17 0.81865591 1537 high scalability-2013-10-25-Stuff The Internet Says On Scalability For October 25th, 2013
18 0.81759506 1502 high scalability-2013-08-16-Stuff The Internet Says On Scalability For August 16, 2013
19 0.81708032 1533 high scalability-2013-10-16-Interview With Google's Ilya Grigorik On His New Book: High Performance Browser Networking
20 0.81634897 946 high scalability-2010-11-22-Strategy: Google Sends Canary Requests into the Data Mine