Dear gentle reader,
You may, at one point, have wondered how to shield innocent Internet users from the vagaries of widget response times. You may have glimpsed Nginx’s proxy_read_timeout configuration and thought it an appropriate way to moderate lag spikes.
You may have been wrong.
I was.
At UserVoice, we were fielding complaints that our widget was slowing down pages, but our rendering times were low thanks to heavy caching. Well after installing New Relic’s RPM, we were quickly able to identify the problem — long Mongrel queue lengths. Given an upcoming hosting transition, and given some complications with further caching improvements, we thought the most expedient short-term fix would be setting a proxy_read_timeout on widgets. The theory: even if we’re slow, it’s not your problem.
But it’s still our problem.
See, nginx worked dutifully and beautifully. Whenever a widget response took too long, it returned a status code that let the client continue browsing. And then it would hand the next request back to the Mongrels … but they weren’t done with the last request, so the new one was just … added to the queue.
Imagine working in an environment where, as soon as you were bogged down, your boss started giving you work faster. You wouldn’t be happy. Neither was Mongrel.
I’m sorry, Mongrel. I’ll do better next time.