There is great joy in doing the wrong thing for the right reasons when it works and no one gets hurt. That’s how things went with our new charting web service, Paparazzi Charts.
Charts are a really important part of the content on Zillow. We generate a lot of complex and interesting data about homes, and charts help our users visualize and understand it. One of our most important metrics is the Zillow Home Value Index (ZHVI), which is used throughout our services, and has also appeared in several academic studies and Congressional testimony. Here’s an example chart of the Zestimate of a home, the ZHVI in the zipcode, and the ZHVI in the city, over time.
Why Paparazzi Wins
When we tested our new charts against our old ones, our users ended up engaging with Zillow ~7% more. Why? People love speed.
Zillow engineers have created some internal tools that help us build great infographics to describe these kinds of size differences .
We staged a shootout across libraries that could render to all three platforms. Dojo charts were the most functional and performant option for our use case. So, we implemented our charts in Dojo to get rid of Flash charting. It had a few quirks that we didn’t like, though. It was more difficult to style than Protovis or D3, the charting layer was pretty heavy, and the second round trip for browser detection slowed it down a bit.
We launched Dojo charts as a test, to collect some real-user behavior metrics. Our users got a little happier without Flash. Downloading and running 200KB of Dojo blocked a little less, and burned a little less CPU than starting up the Flash plugin and running our Flash charting code. We knew we could do better.
Shrinking the Payload
It took an hour to write a script that could take PNG snapshots of any web page. We put that inside a Turbogears web service. Charts started popping up all over the screen on the dev box. So we launched Xvfb, a headless X server implementation, to clean that up. I’d like to tell you that was as far as it went. I’d really like to tell you that we stopped that nonsense and made our Dojo 1.6 charts work on node.js, using minidom and node-canvas. Come to think of it, pretend that’s just what we did.
Whatever we did, it’s rendering most of Zillow’s chart traffic on 40% of an old server, with rock solid uptime.
The Wrong Thing
If you do happen to use Python to run a Webkit browser as a Turbogears web service, rendering to Xvfb, there are a few gotchas to avoid. Or, so I’ve heard. Don’t run WSGI in threaded mode, or mod_python. Spawn processes for better failure isolation. And be sure to use the WSGIServer implementation from flup.server.fcgi_single. The python/gtk eventing bridge really doesn’t like thread hopping and will deadlock on you. Also, use this code to start and stop an Xvfb instance per process.
Good luck, have fun and stay safe!