Yeah the web tier is rarely the bottleneck, can be scaled linearly when it is and typically very susceptible to caching.

I didn't like the presentation of the benchmark either. There isn't enough information to know even what the configuration is (uWSGI or gunicorn? it doesn't say) let alone to replicate the benchmark on your own hardware. It's disappointing that the author doesn't include proper stats like standard dev, nth percentile, etc which would give better impression of what's going on. On top of all of that, it's a microbenchmark that doesn't include the typical db access, caching and so on of a real web application, so it gives a misleading impression of the speedup you could get over another framework.

>Yeah the web tier is rarely the bottleneck,

People say this all the time- While I think it is mostly true, I think it is more often untrue then most would assume. In well optimized systems the "IO layer" is optimized first as it rightly should be, at this point improving the single-threaded performance and concurrency/parallelism start to really matter.

>can be scaled linearly

Sure but scaling my number of servers linearly however doesn't imply linear maintenance/operations effort... If I can run a order of magnitude less severs, I am going to save money. Its all about figuring out if the savings are worth shift to a higher performance platform... but playing devils advocate if one had started with the higher performance platform to begin with...

>when it is and typically very susceptible to caching.

That is making a lot of assumptions about the problem space at hand. But its fair point, when things are catchable, its magical.

Twitter got a 10x reduction in number of front-end web servers and a 10x latency improvement by changing the platform. The layer literally called thrift services and made HTML pages. The 10x reduction in servers was great at the scale that they were at but the 10x decrease in latency was the real winner and it had nothing to do with scale. Pure single request performance.

they probably also rewrote the code (they just didn't change the language) right ?

I think you're asking whether they optimized the rewrite, rather than just ported it from Ruby to Scala? I too would be interested to know if there is any data to this.

That's what happens most of the time.

It was an exact port including bugs — output needed to be exactly the same as that was the best way to test the result. I wouldn't say the Scala code was any more optimized than the Ruby code was over the years. In fact, lots more effort had been put against optimizing the Ruby side (for example, the template engine was written in C for performance).

> Yeah the web tier is rarely the bottleneck

That's not exactly true. For example, as you said, employing a cache may significantly improve performance - essentially to the point where 99% of the time is spent inside framework code (routing, params parsing, etc). In such a situation a "web tier" may become a bottleneck, and when it does it's quite deadly: you can't do anything about it, short of abandoning or changing the framework.

> that doesn't include the typical db access, caching and so on

But that is not what a web framework itself does, right? It doesn't offer ORM layer nor cache layer and it's not being compared to Django, but rather to Bottle (which performed remarkably well) and similar.

Anyway, as to the framework itself: from reading the page I got an impression that it's thread-safe, which would be more than a reason enough to use it were it true. In the past I used Erlang with Cowboy for building performant web apps - it was enjoyable and I liked it, but it also required the skill to do so, which is not that widespread unfortunately. Falcon probably is nowhere near Erlang/Cowboy performance, but it could be just about "fast enough" for most use cases.

> the web tier is rarely the bottleneck

Wikimedia had a lot of success migrating to HHVM. They reported a nice speedup when editing a wikipedia page.

People keep linking to the techempower benchmarks, but last I checked they did _not_ do Python web deployment quite right (i.e., no gevent, no gunicorn, no uWSGI).

Things might have changed in the meantime (on mobile, so hard to check), but despite their benchmarks being open, I don't think there are many contributions from folk who do production deployments...

>but last I checked they did _not_ do Python web deployment quite right (i.e., no gevent, no gunicorn, no uWSGI).

Most of the TechEmpower entries are user submitted; If you feel this is the case you should submit one...

I should, but then again I have no vested interest in showing off a framework or benchmarking stuff I'm not going to run myself. There is only so much free time...

There are many reasons I might want a framework that emphasizes speed but am unable or unwilling to abandon Python.

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.

Came here to say this. In my humble opinion, the creator of Falcon should write at least 1 very clear paragraph to explain how this framework is better or just different from Flask. Flask is such an amazing piece of software, you'll need to make the case for me to use it much clearer than it is now. From its APIs to not having a templating engine included and strange things like hooks.to_oid, I don't see why I would use Falcon over Tornado or Bottle either.

The biggest reason would be that you're building a REST API and you want something tailored for that use case. If you're not building a REST API (but instead for example a web site serving HTML and whatnot), you shouldn't use Falcon at all.

This might not be clear on the Falcon framework home page though, and I will let the maintainer know it might be a good idea to clarify this point.

Cool, then Falcon is actually better off if it's suited for a more specific use-case like this.

Flask has a fantastic REST API extension (Flask-restless), so I'd go for a very targeted comparison between that and Falcon. Having more competition here can only be a good thing, I wish you the best of luck!

Flask is great. Off the top of my head, Falcon's smaller dependency list is nice if you're managing server environments. Flask currently depends on Werkzeug, Jinja2, itsdangerous, and markupsafe, as opposed to just six and mimeparse for Falcon.

That is a nice competitive advantage over Flask, but Bottle has no dependencies whatsoever. And besides a slight performance advantage over Bottle, I don't see any significant reason for me to switch to Falcon.

I'd like to know which aspects of Falcon's usability where found painful. I actually find it to be really friendly while coding, but I don't try to use it for stuff it's not designed for.

I reason that it's not a matter of why are you using Python but more of we/I (must) use/prefer/know Python better than other languages.

This is a stupid comment, since whatever language you use will run into bottlenecks. What is important is how you design your architecture, is it distributed, are long running processes handled by a task manager, caching, how are you serving up your files, vids, imgs, does your db have the right indexes, is your schema optimal, geez we can go on and on. You are 100% fine running python just like Instagram, Dropbox, Yelp and many other startups did and still do. Stop distributing this FUD.

I think you are missing the point of the parent comment. He is trying to convey similar message as you are. The difference is he is not being a jerk about it.