Tigraine

Daniel Hoelbling-Inzko talks about programming

Generating synthetic CPU load on Linux

While working on some alerting and metric collection about our infrastructure at Bitmovin I wanted to test out if the alerts I configured are actually triggered when a server experiences high CPU load.

I came across this beautiful Stackoverflow Answer that did exactly what I needed:

seq 3 | xargs -P0 -n1 md5sum /dev/zero

This command will saturate 3 cores with 100% user load until you cancel the command with CRTL+C.

Filed under linux, devops, server

The story of NginX, Facebook and ipv6

I just released my professional photography website to the public and was quite content with the setup. The site is running Wordpress on php5-fpm proxied through NginX. I optimized the hell out of the site using w3-total-cache, and the NginX + php5-fpm setup delivers superb performance.

Only Google and Facebook where giving me a hard time with site-verifications and other checks to see if tracking codes are correctly embedded. After digging a bit I noticed that the Facebook Linter was only seeing "Welcome to NginX" which is the default site set up on the server.

So I started taking apart my NginX configuration, testing different things and even though I could access the site correctly using Chrome, sometimes on other computers it would still show the default page. I was puzzled to say the least. Also Chrome makes it exceptionally hard to debug these problems due to being too smart. I had deliberately set up the site to only be available without www and was planning on configuring the 301 redirect, but somehow forgot to - turns out Google did it all by himself and never told me about it. So I was there thinking the site 301 redirects, but instead people with certain browsers ended up seeing the Nginx default page.

Once I realized that curl on my server was also only returning the default page it started to dawn on me. I had set up a AAAA record by default, and NginX was listening for ipv6 traffic, just the photography host was not configured to listen for it. So any requests that came in through ipv6 where hitting the default_server, not the actual host. Once I configured the listen [::]:80; ## listen for ipv6 line in my nginx host configuration everything started to work as expected and also Facebook started to see the page.

So lesson learned: Facebook tries ipv6 if possible, and if your server has a ipv6 DNS record but is not configured correctly, users will see your site (due to the browsers being smart), but crawlers may miss it. So always check v6 connectivity when launching a new site.

Filed under server, nginx, facebook, ipv6, network

Interessanter Ansatz für ein Server-Protokoll

Ich glaube mir ist aus Versehen was interessantes gelungen.

Im Rechnernetze Kurs an der Uni war von uns gefragt ein eigenes Protokoll für einen Socket Server unter Java zu entwerfen.

Im Grunde wollten man wohl ein relativ simples HTTP ähnliches Protokoll mit GET, POST und LIST von uns. Ich musste aber natürlich über das Ziel hinwegballern.

Rausgekommen ist ein IMAP ähnlicher Socket-Server der nicht nur für jedes Socket einen Thread öffnet sondern auch für jeden Command einen weiteren startet um nie zu blockieren. Und auch wenn das jetzt ziemlich brutal klingt, der tiefere Sinn dahinter war der dass man dadurch Befehle aneinanderreihen kann und das im Server sehr simpel über Thread.join() gelöst wird.

Spezielles zum Konzept und der Paket Syntax gibts unter more.

Java Source Code of Packet Spec

Sämtliche Befehle werden mit einem Token prefixed (wie in IMAP) und dieser Token wird vom ClientHandler (der eigene Thread für jeden Client) in einer Hashtable als Key angelegt während der zu launchende Thread (CommandExecution) die Value ist. Existiert der Key bereits in der Hashtable so wird der alte Thread durch den gerade neuen ersetzt und der neue macht Thread.join() auf den alten. Dadurch wird der neue erst ausgeführt wenn der alte Befehl abgearbeitet ist, also dessen run() Methode durch ist. Der Token diehnt auch dazu dass der Client die Response vom Server zuordnen kann (wie in IMAP).

Was auf jeden Fall noch verändert werden muss bevor man damit irgendwas bauen kann ist dass alles auf Threadpools umgebaut werden muss (Das andauernde Threads starten frisst enorm Ressourcen). Außerdem ist der Server momentan sehr verwundbar gegen DoS Attacken.

Ich werde versuchen bis nächste Woche mal den Java Code soweit aufzubereiten dass ich ihn ohne mir Spott und Hohn einzuhandeln hier unter der GPL herzeigen kann.

My Photography business

Projects

dynamic css for .NET

Archives

more