Skip to content

Category: Performance

Load, Load Testing and Benchmarking

(In order to be able to give up the test blog at blogspot.nl, I am moving content over)

So you have a new system and want to know what the load limits are. For that you want to run a benchmark.

Basic Benchmarking

The main plan looks like this:

The basic idea: Find a box, offer load, see what happens, learn.

You grab a box and find a method to generate load. Eventually the box will be fully loaded and you will notice this somehow.

Leave a Comment

Hipsterdoom with Mongobingo

Felix Gessert does a postmortem of the failed Parse startup and product: “The AWS and MongoDB Infrastructure of Parse: Lessons Learned“.

Technical problem II: the real problem and bottleneck was not the API servers but almost always the shared MongoDB database cluster.

And that was with MongoRocks (Mongo on RocksDB) and replacing the initial app in Ruby with a Go implementation of said thing, with WriteConcern = 1, and other horrible presets. All in all, this is like the perfect nightmare of startup architecture decisions.

Felix closes pointing at his current project:

If this idea sounds interesting to you, have a look at Baqend. It is a high-performance BaaS that focuses on web performance through transparent caching and scalability through auto-sharding and polyglot persistence.

Bingo. Also, found the Hipster.

Leave a Comment

The 2017 web is bloated and slow, and I am guilty, too.

Dan Luu has been benchmarking the web, using Webpagetest and other means. Turns out we have given up on optimization – we are doing too many requests, have too many dependencies and our files are just too large.

This site is no exception.

If you are running on Dialup connection or 3G speeds, or add packet loss, everything goes to hell, and most things don’t even load any more.

Only blog.fefe.de soldiers on.

2 Comments

FOSDEM: Graphite @ Scale at Booking.com

Validimir Smirnov gave his talk Graphite @ Scale at FOSDEM.

The slides (PDF) are available for download, and the talk can be downloaded (webm) as well.

Booking stores about 130 TB of data in Graphite, using 32 frontend and 200 SSD storage servers to collect 2.5M unique metric per second,  worth 11 Gbps of traffic in the graphite backend.

This is achieves mostly be replacing all parts of Graphite with API-compatible rewrites in Go and C, all of which are open source.

Leave a Comment

Dave Täht, LEDE and CoDel

Dave Täht

This is Dave Täht. Dave is working on LEDE. If you have been working with OpenWRT in the past, you should switch to LEDE. You should also give a lot of money to the Patreon of Dave.

Why should you be doing this?

Dave has been working on Networking Theory and Practice, and has been implementing CoDel. CoDel is one of the few innovations in basic networking, a queueing theory and algorithm that can make thick and fast internet pipes actually fast and efficient by managing buffer memory right.  That means that your Internet is fast, and feels fast, even if it is busy.

Getting CoDel right on Wifi is doubly hard because of interaction between the CoDel queues, Wifi media access control and Wifi encryption. But Dave has done that, and it’s part of LEDE.

So, you should

1 Comment

Damian Gryski on Go Slices and CPU Caches

Booking.com’s Damian Gryski on Go Slices and CPU caches (17 minutes, english language)

The dot Post: »Modern computers have multiple layers of caches between the processor and main memory. Algorithms which effectively use these caches can be orders of magnitude faster than those that don’t. Damian looks at how using slices can make your inner loops more cache friendly.«

1 Comment