Puppet "pure fact-driven" nodeless configuration
Truth should guide your configuration management tools.
Truth in this case is: what machines you have, properties of those machines, roles for those machines, etc. For example “foo-1.a.example.com is a webserver” is a piece of truth. Where and how you store truth is up to you and out of scope for this post.
My goal is to have truth steer everything about my infrastructure. Roles, jobs, and even long-term one-offs get put into the truth source (like a machine role, etc).
Debugging java threads with top(1) and jstack.
At work, we’re testing some new real-time bidding on ADX and are working through some performance issues.
Our server is jetty + our code, and we’re seeing performance problems at relatively low QPS.
The first profiling attempt used YJP, but when it was attached to our server, the system load went up quickly and looked like this:
load average: 2671.04, 1653.95, 771.93
Not good; the load average while running with the profiler attached jumps to a number roughly equal to the number of application threads (3000 jetty threads).
SSL handshake latency and HTTPS optimizations.
At work today, I started investigating the latency differences for similar requests between HTTP and HTTPS. Historically, I was running with the assumption that higher latency on HTTPS (SSL) traffic was to be expected since SSL handshakes are more CPU intensive. I didn’t really think about the network consequences of SSL until today.
It’s all in the handshake.
TCP handshake is a 3-packet event. The client sends 2 packets, the server sends 1.
Headless wrapper for ephemeral X servers
For various projects I’m doing right now, I need an easy way to automatically run code in an X server that may not necessarily be the active display. This code may even run on servers in production that don’t have video cards or monitors attached.
For some history on this, check out this post on xvfb and firefox. You can solve the problem in that post by simply launching firefox with the tool below, and your X server will exit when firefox exits.
Xvfb + Firefox
Resig has a bunch of unit tests he does to make sure jQuery works properly on whatever browser. Manually running and checking unit test results is annoying and time consuming. Let’s automate this.
Update (May 2010): See this post for more details on automating xserver startup without having to worry about display numbers (:1, :2, etc).
Combine something simple like Firefox and Xvfb (X Virtual Frame Buffer), and you’ve got a simple way to run Firefox without a visible display.