high_scalability high_scalability-2014 high_scalability-2014-1652 knowledge-graph by maker-knowledge-mining

1652 high scalability-2014-05-21-9 Principles of High Performance Programs


meta infos for this blog

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.


Summary: the most important sentenses genereted by tfidf model

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]


similar blogs computed by tfidf model

tfidf for this blog:

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)]

similar blogs list:

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.

2 0.13325399 1616 high scalability-2014-03-20-Paper: Log-structured Memory for DRAM-based Storage - High Memory Utilization Plus High Performance

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

7 0.12468621 1456 high scalability-2013-05-13-The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution

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

10 0.11387225 1643 high scalability-2014-05-06-The Quest for Database Scale: the 1 M TPS challenge - Three Design Points and Five common Bottlenecks to avoid

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


similar blogs computed by lsi model

lsi for this blog:

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)]

similar blogs list:

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

6 0.76740223 1616 high scalability-2014-03-20-Paper: Log-structured Memory for DRAM-based Storage - High Memory Utilization Plus High Performance

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


similar blogs computed by lda model

lda for this blog:

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)]

similar blogs list:

simIndex simValue blogId blogTitle

1 0.938757 1555 high scalability-2013-11-27-Hidden History: Driving the Last Spike of the Transcontinental Railroad was an Early Version of the Internet of Things

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

14 0.82231766 1293 high scalability-2012-07-30-Prismatic Architecture - Using Machine Learning on Social Networks to Figure Out What You Should Read on the Web

15 0.81964153 573 high scalability-2009-04-16-Serving 250M quotes-day at CNBC.com with aiCache

16 0.81949162 1643 high scalability-2014-05-06-The Quest for Database Scale: the 1 M TPS challenge - Three Design Points and Five common Bottlenecks to avoid

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