INFOQ: Comparing Virtual Machines and Linux Containers Performance
The paper authors ran CPU, memory, network and I/O benchmarks against native, container and virtualized execution,
using KVM and Docker as virtualization and container technologies respectively.
Benchmarks also include sample Redis and MySQL workloads;
Redis exercises the networking stack, with small packets and a large number of clients,
while MySQL stresses memory, network and the filesystem.
The results show that Docker equals or exceeds KVM performance in every case tested.
For CPU and memory performance KVM and Docker introduce a measurable but negligible overhead,
although for I/O intensive applications both require tuning.
Docker performance degrades when using files stored in AUFS, compared to using volumes, that have better performance.
A volume is a specially-designated directory within one or more containers that bypasses the union file system,
so it does not have the overhead that the storage backends may have.
The default AUFS backend causes significant I/O overhead
specially when using many layers and deep nested directory hierarchies.
Be warned that this is mostly just a collection of links to articles and demos by smarter people than I. Areas of interest include Java, C++, Scala, Go, Rust, Python, Networking, Cloud, Containers, Machine Learning, the Web, Visualization, Linux, System Performance, Software Architecture, Microservices, Functional Programming....
Wednesday, 20 August 2014
Friday, 11 July 2014
Why Twitter picked Scala...
Engineer-to-Engineer Talk: How and Why Twitter Uses Scala
Intesting quote:
Intesting quote:
We knew we needed another language. How did we pick a language that was really fun for us? We considered Java, C/C++ of course. And we looked at Haskell and OCaml for functional programming, though neither has gotten much commercial use. Erlang developers are doing stuff with a lot of network I/O but not with a lot of disk I/O; the knowledge-base around the language wasn’t great though, and the community seemed inaccessible.Java is easy to use, but it’s not very fun, especially if you’ve been using Ruby for a while. Java’s productive, but it’s just not sexy anymore. C++ was barely considered as an option. Some guys said, if I have to work in C++ again, I’m going to stab my eyes out with a shrimp fork. Java-script on the server-side via Rhino had performance problems, and it wasn’t quite there yet when we were evaluating it.
So what were our criteria for choosing Scala? Well first we asked, was it fast, and fun, and good for long-running process? Does it have advanced features? Can you be productive quickly? Developers of the language itself had to be accessible to us as we’d been burned by Ruby in that respect. Ruby’s developers had been clear about focusing it on fun, even sometimes at the expense of performance. They understood our concerns about enterprise-class support and sometimes had other priorities.
We wanted to be able to talk to the guys building the language, not to steer the language, but at least to have a conversation with them.
Monday, 16 June 2014
Thoughtworks Technology Radar
Thoughtworks Technology Radar : Languages and Frameworks
They recommend only enabling the "good parts" of Scala with feature flags.
They recommend only enabling the "good parts" of Scala with feature flags.
Friday, 13 June 2014
Adam Thornhill : Code as a Crime Scene
Code as a Crime Scene
To understand large-scale software systems we need to look at their evolution. The history of our system provides us with data we cannot derive from a single snapshot of the source code. Instead Versions Control System (VCS) data blends technical, social and organizational information along a temporal axis that let us map out our interaction patterns in the code. Analyzing these patterns gives us early warnings on potential design issues and development bottlenecks, as well as suggesting new modularities based on actual interactions with the code. Addressing these issues saves costs, simplifies maintenance and let us evolve our systems in the direction of how we actually work with the code.
The road ahead points to a wider application of the techniques. While this article focused on analyzing the design aspect of software, reading code is a harder problem to solve. Integrating analysis of VCS data in the daily workflow of the programmer would allow such a system to provide reading recommendations. For example, “programmers that read the code for the Communication module also checked-out the UserStatistics module” is a likely future recommendation to be seen in your favorite IDE.
Integrating VCS data into our daily workflow would allow future analysis methods to be more fine-grained. There's much improvement to be made if we could consider the time-scale within a single commit. As such, VCS data serves as both feedback and a helpful guide.
Thursday, 12 June 2014
Saturday, 7 June 2014
Twitter-Scale Computing with OpenJDK
Friday, 6 June 2014
Data-crunching is better done with Statically typed languages
Subscribe to:
Posts (Atom)