How frequently has your selection of web-framework ultimately been the limiting factor leading to a real-life performance bottleneck?

I've dealt with python scaling issues up to thousands of simultaneously active users and the performance bottlenecks have yet to boil down to the difference between which web-framework was used.

I agree there are certainly use-cases for a speedy python web-framework.

I am not sure I agree with refusing to abandon Python at all/high costs, and I question the value of Falcon for most of us. Since Falcon is well-suited to such a narrow band of use case(s), in most instances it contributes to the background noise of obscure web-frameworks.

Not all projects are the same. I've used cherrypy over django, for example, when I needed a simple encapsulated application for self-hosting. My point is, Python arguably is not the best choice for a self hosted product so you could dismiss cherrypy with the same argument you made. But we don't often get the joy of solving problems with just a single constraint.

Above all I'm against dismissing something by reflex and crowing about it in a comment. He built it. He's clearly given the problem some thought. What value really is there in dismissing it so quickly and on the grounds of "Python is the wrong choice for this anyway.."

This comment only shows that you don't understand Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_law)

If it takes 10s for your Python code to serve a request, it doesn't matter if the framework takes 1s or 0.1s to parse http headers and call you. The 0.1s framework is 10x faster than 1s framework but it only makes <10% difference on metric that you really care about.

The only way to actually make a 10x difference on "time to serve a request" metric is to switch to a more performant language, like C# or Java or Go.

(and I'm using seconds for illustration purposes only, in real life the timing would be in milli-seconds, but the same logic apply)

don't be a dick; also, you don't know what you're talking about. It's entirely possible that the guy's code is dominated by routing performance or copying.

> don't be a dick; also, you don't know what you're talking about.

The GP shouldn't have included that dig, but this comment would also be strictly better without the first sentence.

>"It's entirely possible that the guy's code is dominated by routing performance or copying." Like that recent Netflix issue. Though that was node.js.