Stuff The Internet Says On Scalability For October 12, 2012

It's HighScalability Time:

• Quotable Quotes:
  • @rodos: With so much manure in the room of #BigData the must be a pony in here somewhere!
  • @adron: #ricon2012 OH "it isn't cloud, nosql or whatever, it's distributed systems... That is the change!" Smartest thing stated at a conf in ages.
  • @justinesherry: First lesson watching @eric_brewer's keynote at #ricon2012 -- distributed systems make you go bald. (Both audience and speaker!)
  • @adron: OH "What's the hello world of distributed systems?" "Twitter."
  • Mikael Ronstrom: A long career on distributed systems has learnt me that it is extremely important to do proper partitioning of data sets to achieve scalability on network level. But it is still extremely important to make each node in the distributed system as large as possible. 
  • Greg Linden: Surprising: "It can be three to four times the cost for the retailer to pick items and pack them from a store versus having a really efficient, automated process back in a distribution center."
  • Dan Rayburn: CDNs Account For 40% Of The Overall Traffic Volume Flowing Into ISP Networks


• One minute and 19 seconds into launch the Falcon 9 lost one of its nine engines. Software apapted by detecting engine failure, cutting the fuel supply, and then distributing the unused propellant to the remaining engines, allowing them to burn longer. How cool is that! That's High Availability in practice. That smooth SpaceX launch? Turns out one of the engines came apart.


• When is kilo 1000 and when is it 1024? Thank the bit lords the values are so close because there's a kiloton of confusion on this point, as is shown by the conversation around Whats the Difference Between Kbps and kBps ?


• Update on a previous slime mold article: Organism without a brain creates external memories for navigation shows slime mold is even cooler than originally thought, storing a record of where it's been using slime: The authors conclude, the slime isn't just the mold's calling card. Instead, it's a way of marking the environment so that the organism can sense where it's been, and not expend effort on searches that won't pay off. Although the situation isn't an exact parallel, the authors make a comparison to the pheromone trails used by ants. 


• Bitly with a indepth explanation about using NSQ: realtime distributed message processing at scale to process ~35,000 messages/second at peak. NSQ is written in Go, eliminates SPOF, bounded memory usage, easy configuration, stonger message delivery guarantees. 


• Cache is King. Performance guru Steve Souders found caching is perhaps the biggest factor in creating fast web pages. A primed cache was faster than having a fast network or a no javascript pages. So cache pages longer and find ways to precache resources. 


• Six themes from Velocity Europe: Performance matters more — The places and ways that web performance matters keeps growing; Organizational challenges are the hardest — Lonely Planet and SoundCloud talked about how the challenges in shifting their organizational culture to focus on performance were more difficult than the technical work; The community is huge — As of today there are 42 web performance meetup groups totaling nearly 15,000 members worldwide;  


• Scaling MySQL and MariaDB to TBs: Interview with Martín Farach-Colton. Roberto Zicari with a really great interview talking about TokuDB's fractial tree technology: In a Fractal Tree Index, all changes — insertions, deletions, updates, schema changes — are messages that get injected into the tree. Even though these messages get injected into the root and might get moved several times before getting to a leaf, all queries will see all relevant messages. Thus, injecting a message is fast, and queries reflect the effects of a message, e.g., changing a field or adding a column, immediately.


• DNS server in Go - Big NTP Pool upgrade: If you need less than 200 DNS lookups per second per DNS server the Perl version is fine and might be a little easier to setup. The Go version is much faster (in prodution we've seen it do 5-6000 requests a second on commodity hardware and even virtual servers).


• Lessons from Why Zynga Failed: Users moving to more complex games; Facebook ad increases trippled the cost of acquriring new customers; Facebook snipped the viral loop; Facebook started charging a tax; Mobile shifted game interaction from chores and virtual property to engagement.


• Papers are now available for OSDI '12 Program. Sections include papers on Big Data, Privacy, Mobility, Distributed Systems and Networking, Security, Potpourri, Replication, Testing and Debugging, and Isolation.


• Characterizing the Scalability of Erlang VM on Many-core Processors: Results show that the current version of Erlang VM achieves good scalability on the processor with most benchmarks used. The maximum speedup is from about 40 to 50 on 60 cores. Synchronization overhead caused by contention is a major bottleneck of the system. Another major problem is that the parallel version of the virtual machine using one core is much slower than the sequential version with a benchmark program containing a huge amount of message passing.


• Good Google Groups discussion on what is more important (RAM vs Cores). I really liked Viktor Jevdokimov response: IMO, in most cases you'll be limited by the RAM first. Take into account size of sstables, you will need to keep bloom filters and indexes in RAM and if it will not fit, 4 cores, or 24 cores doesn't matter, except you're on SSD.  You need to design first, stress test second, conclude last. 


• P. Lutus with a good straightforward MySQL Tut orial 1: Overview, Tables, Queries.


• Bandwidth-based Experience. eBay shows how to use load time to select what content to serve. Improve performance for low-bandwidth users by: Show fewer results; Use smaller images; Cut down on heavy ads, or remove all ads; Remove heavy or crazy features that are not required for basic functionality.


• $99 Raspberry Pi-sized “supercomputer” touted in Kickstarter project. While perhaps not the most efficient way to connect gobs of cores together, it's a cool project. I look forward to a new programming language called Tart to program this beast.  


• If you aren't aware of Boundary they are doing a lot of great work pushing architecture and talking about it on their blog. In recent tests Boundary found Java is faster than Go. Not all that surprising given Go's youthfulness. But all is not lost Golings, Kevin Gillette in the comments described how he profiled the code, made some tweaks, bringing the test up to 16k rps for Go, compared to 10k rps for Java. Usual benchmarking BS applies. A lot of tweaking to get performance can be a sign of immaturity or a sign that a systematic choice was made to prefer a certain programming model over performance, but it's interesting to note that the technologies are at least comparable. 


• Scalability improvements in MySQL 5.6:  Splitting InnoDB Kernel mutex; The G5 discovery; Splitting LOCK_open mutex; Binlog group commit. 


• Composable Incremental and Iterative Data-Parallel Computation with Naiad: We report on the design and implementation of Naiad, a set of declarative data-parallel language extensions and an associated runtime supporting efficient and composable incremental and iterative computation. This combination is enabled by a new computational model we call differential dataflow, in which incremental computation can be performed using a partial, rather than total, order on time.


• Making Geo-Replicated Systems Fast as Possible, Consistent when Necessary: First, we propose RedBlue consistency, which enables blue operations to be fast (and eventually consistent) while the remaining red operations are strongly consistent (and slow). Second, to make use of fast operation whenever possible and only resort to strong consistency when needed, we identify conditions delineating when operations can be blue and must be red

This week's selection: