Simon Willison’s Weblog

nginx proxy-cache-lock (via) Crucially important feature hidden away in the nginx documentation: proxy_cache_lock enables request coalescing, or dog-pile protection: it means that if a hundred simultaneous requests all suffer the same cache miss, only one request is made to the backend and the answer is then sent back to all hundred requests at once. I’ve leaned heavily on this feature in Varnish for years—useful to know that nginx has the same capability.

# 14th November 2017, 9:53 pm / nginx, caching, varnish, dogpile

Display your events on your own website with Lanyrd Badges. We’ve launched badges for Lanyrd—JavaScript that lets you embed a top bar or a content “splat” showing events you plan to attend, talks you’ve given in the past and other various combinations. I’m quite pleased with the implementation—the badges are configured using classes on a link to your Lanyrd profile, and the badges themselves are served through a combination of Amazon CloudFront for the initial script and a Varnish cache for the badge data itself to keep things nice and snappy.

# 13th January 2011, 8:38 pm / badges, caching, cloudfront, javascript, lanyrd, varnish, recovered

Why toppcloud will not be agnostic. Ian Bicking’s toppcloud aims to offer deployment with the ease of use of AppEngine against a standard, open source Ubuntu + Python 2.6 + mod_wsgi + Varnish stack. Here he explains why he’s not going to vary the required components: keeping everything completely standardised means everyone gets the same bugs (and the same fixes).

# 12th February 2010, 9:21 am / ian-bicking, deployment, django, python, modwsgi, wsgi, ubuntu, varnish, toppcloud, appengine

Traffic Server. Mark Nottingham explains the release of Traffic Server, a new Apache Incubator open source project donated by Yahoo! using code originally developed at Inktomi around a decade ago. Traffic Server is a HTTP proxy/cache, similar to Squid and Varnish (though Traffic Server acts as both a forward and reverse proxy, whereas Varnish only handles reverse).

# 1st November 2009, 12:15 pm / trafficserver, yahoo, inktomi, mark-nottingham, open-source, apache, http, cache, proxy, squid, varnish

High-end Varnish-tuning. Tuning the Varnish HTTP cache to serve 27K requests/second on a single core 2.2GHz Opteron.

# 20th October 2009, 9:25 am / varnish, performance, caching, http

Yahoo! proposal to open source “Traffic Server” via the ASF. Traffic Server is a “fast, scalable and extensible HTTP/1.1 compliant caching proxy server” (presumably equivalent to things like Squid and Varnish) originally acquired from Inktomi and developed internally at Yahoo! for the past three years, which has been benchmarked handling 35,000 req/s on a single box. No source code yet but it looks like the release will arrive pretty soon.

# 7th July 2009, 12:37 pm / trafficserver, yahoo, open-source, caching, proxy, squid, varnish, apache, asf

Installing Django, Solr, Varnish and Supervisord with Buildout. Useful, detailed instructions... but I still think this stuff is Way Too Difficult at the moment. I’m a big fan of the idea of sites that are assembled from multiple smaller web services talking HTTP to each other, but ensuring all the moving parts stay running is massively more painful than just running Apache and MySQL.

# 7th June 2009, 1:54 pm / apache, mysql, sysadmin, operations, rest, django, solr, varnish, supervisord, buildout, python, bertrandmathieu

How search.twitter.com uses Varnish. Includes examples of the configuration options they use.

# 2nd March 2009, 5:08 pm / twitter, varnish, search, caching

Just what web server should be sitting in front of my Rails application? Includes some interesting notes about Varnish, PHK’s high performance, highly configurable front-end caching server (essentially a much more modern version of Squid).

# 17th July 2007, 1:29 pm / varnish, phk, joyent, rails, squid, nginx, jason-hoffman