Month: January 2013

Dead Link: Stand-alone jemalloc

Dead Link: Stand-alone jemalloc

jemalloc started out as the memory allocator for a programming language runtime in 2005, but language design changes made the allocator superfluous. At the time, FreeBSD was in need of an SMP-scalable allocator, so I integrated jemalloc into FreeBSD’s libc, and then made a long series of improvements to scalability and fragmentation behavior.

In late 2007, the Mozilla Project was hard at work improving Firefox’s memory usage for the 3.0 release, and jemalloc was used to solve fragmentation problems for Firefox on Microsoft Windows platforms. You can read here about the fruits of that labor. I made many enhancements to jemalloc while developing for Mozilla, and all of the generic algorithmic improvements were incorporated into FreeBSD’s jemalloc. More recently, Mozilla sponsored integration of Apple Mac OS X support into the stand-alone jemalloc.

Since 2009 I have adapted jemalloc to handle the extreme loads Facebook servers commonly operate under. Facebook uses jemalloc in many components that are integral to serving its website. Facebook supports numerous open source projects, and is to thank for sponsoring many of the features that first appeared in the stand-alone jemalloc.

Varnish Community | Varnish makes websites fly!

Varnish Community | Varnish makes websites fly!

Varnish is a web application accelerator. You install it in front of your web application and it will speed it up significantly.

Varnish is a caching HTTP reverse proxy. It receives requests from clients and tries to answer them from the cache. If Varnish cannot answer the request from the cache it will forward the request to the backend, fetch the response, store it in the cache and deliver it to the client.

When Varnish has a cached response ready it is typically delivered in a matter of microseconds, two orders of magnitude faster than your typical backend server, so you want to make sure to have Varnish answer as many of the requests as possible directly from the cache.

Varnish decides whether it can store the content or not based on the response it gets back from the backend. The backend can instruct Varnish to cache the content with the HTTP response header Cache-Control. There are a few conditions where Varnish will not cache, the most common one being the use of cookies. Since cookies indicates a client-specific web object, Varnish will by default not cache it.

This behaviour as most of Varnish functionality can be changed using policies written in the Varnish Configuration Language (VCL). See The Varnish Users Guide for more information on how to do that.