[hansvm]

The "most of your response time is spent waiting on the DB" assumption might not hold for your app. Even if you actively push work to the DB to reduce network bandwidth or something, your workload might fundamentally be comprised of small, easy-to-optimize units of work that the DB handles without any issues.

That said, hundreds of milliseconds sounds slow by an order of magnitude or more for html rendering, even if all the work is done in a batteries-included framework for a dynamic language, and it doesn't jive with my Python experience at all. Do you mind me asking what kinds of tasks are taking that much time?

[jrochkind1]

In this app, mostly lots and lots of thumbnails. It may be some unoptimized code.

But rather than get into the details of my app, and parts that need optimization (whether in my local code or in Rails or in ruby), I'm more curious about the overall concept.

Are you sure that most of your web app's time is spent waiting on the DB? My suspicion has become that this is conventional wisdom that is not actually true of most apps anymore. But I could be wrong. Or I could be right only for Rails and not python because Rails is slower than typical python, or something. I am curious to find out.

[hansvm]

> Are you sure that most of your web app's time is spent waiting on the DB?

Positive. It's my first tech job though, and we use C# at work to the extent that matters.

The kind of Python I write off the clock probably isn't a good example of waiting on the DB though. It's usually a thin wrapper around C or assembly (or calling into such a library via numpy, networkx, etc) to do something horrendously expensive that I absolutely would not want to run in vanilla cpython. That said, when I do ordinaryish web-related stuff in Python I'm looking at well under 20ms total elapsed time per call, which is why your ~200ms html rendering time stuck out to me.