3 ms·
I appreciate the kind words. :) Of course profiling is important. Even with starting on a greenfield project of this scale, I don't think I'd choose Go (which
by mattrobenolt 13y ago
I appreciate the kind words. :) Of course profiling is important.
Even with starting on a greenfield project of this scale, I don't think I'd choose Go (which I spend a lot of time writing). The ecosystems aren't as mature in libraries and whatnot as Python is.
But aside from that, we do profile, and we know that we have some bottlenecks with actual query time. Not to say that this is the sole contributor, but it plays a role.
And you're right about us being in a position to be able to leverage Varnish to it's fullest. We have a large number of reads vs writes, and a large percentage of those are anonymous users.
Even if we had a faster backend, I don't see why we'd avoid something as simple and useful as Varnish. Even caching things for 1 second is invaluable when doing 45k/s. Even if our backend was some super optimized C code, it's pointless.
Varnish also provides us some other benefits, like being able to serve a "stale" version if we're down and smooth over hiccups.
- bhauer 13y ago> Even if we had a faster backend, I don't see why we'd avoid something as simple and useful as Varnish Agreed! Since as you show in your post, it's quite effortless to set up, it's often a great idea to have a reverse proxy cache to deal with whatever cacheable responses your application generates (be it many or just a few request types). I just want readers to be aware that for systems with a much more modest usage load (say ~1k RPS), a high-performance system can enjoy a slightly less complex system architecture. Ultimately, it's a decision for the application's designer to make. As you point out, there are other non-performance upsides to a reverse proxy. I love the ability to blip (technical term?) the application server and know the reverse proxy keeps a portion of users unaware. :)