Milan Simonovic
Benchmarking Node.js app running on DigitalOcean
In this post I talk about an unexpected finding from 2021, discovered while rearchitecting and benchmarking a backend API running on DigitalOcean.
The starting point was an expressjs app running on a Digital Ocean droplet:
Before making any changes I do the initial benchmark to establish the baseline and got about 10 req/sec throughput.
Quantifying the effect of location on Swiss multi-family house prices
It doesn’t take long before one discovers that in real-estate location is key:
Location, location, location. You may have heard this mantra when talking to an agent about the home values. In a nutshell, it means homes can vary widely in value due to their location. For example, the median cost of a single-family home in Decatur, Ill., is $107,900. The median cost of a single-family home in the Honolulu, Hawaii, area is $813,500. Location is essential when it comes to the value of a property.
Jepsen-testing RabbitMQ [with python] - Part 2
This is the second post about my efforts to reproduce the Jepsen RabbitMQ test (using python). The first one failed to reproduce data loss by cutting the network in half the same way every time. Here I’ll try different partitioning schemes.
First, let’s try the blockade’s random partitions:
This is implemented as a nemesis in blockade_random_partitions-rabbitmq-test.py.
Jepsen-testing RabbitMQ [with python]
UPDATE: the code is now available on GitHub https://github.com/mbsimonovic/jepsen-python
In this post I’ll tell you about trying to reproduce the Jepsen RabbitMQ test (using python, not clojure). It’s been more than 2 years since the test, and rabbitmq went from 3.3 to 3.6 meanwhile, so I was wondering if anything’s different these days (end of 2016).
Messaging is a legit communication pattern, as nicely documented in the Enterprise Integration Patterns (2003) book, and with the rise of microservices it’s even more relevant that it was 10-15yrs ago.
Branding as an unfair advantage
There was an interesting point made at the previous Zürich Lean Startup meetup event (slides are available here), Michael Wiedemann argued branding could be used as an unfair advantage.
If you’re not familiar, the concept was introduced by Ash Maurya in his book Running Lean (quoting Jason Cohen):
A real unfair advantage is one that cannot easily be copied or bought.
In dubio pro reo
Smashing CouchBase
You might remember year 2k for Bill Gates stepping down as CEO (and promoting Steve Balmer), American Beauty winning 5 Oscars, liberation of Lebanon after 22 years of Israeli occupation, end of RSA patent, Bill Clinton becoming the first U.S. president to visit Vietnam, and I will certainly remember it for the Bulldozer Revolution in my country which lead to the resignation of Slobodan Milošević.
That year marks a big milestone in the world of software engineering: in a conference keynote, prof. Eric Brewer postulated the now famous and much discussed CAP theorem (btw it was proven 2 years later by Gilbert and Lynch), and paved the way for the NoSQL revolution.
Another big factor for NoSQL was getting away from the relational model (proposed way back in 1969) and ACID to achieve scale, performance. Having felt the pain of working with object-relational mappers, developing a webapp on MongoDB for the first time was such a pleasant experience.
Tasting first CouchBase
In this post I’ll tell you about installing and using CouchBase in a test-first manner. Wiping out all the data between tests turned out to be very slow - 4s per test [MB-7965], and for anything but key lookups indexes have to be used, so the elephant is still in the room. CouchBase’s async nature makes setting up testing infrastructure a bit more difficult compared to MongoDB or relational databases.
I’ve used MongoDB for a couple of projects at work (http://pax-db.org); it’s great for read-only data, logs and analytics.
It turned out to be rather difficult to operate (puppetize, coordinating replicasets initialization, watching oplog, …); consistent hashing over a set of equal nodes sounds like it’s more likely to work reliably than async master-slave (plus seems more efficient - mongo secondaries are not used to serve content); sharding+replica sets is way more painful than elastically growing (and shrinking!) a dynamo-like system; plus mongodb can and will lose data (under network partitions).