Falcon is a high-performance Python Web framework
falconframework.org
falconframework.org
Is the performance difference between Django+TastyPie, Flask, or Falcon really going to be the bottleneck holding you back from achieving greatness? If so..then maybe it's better to consider a different tool set.
Any number of other high-performance solutions fit the bill: Go, Java JAXRS, etc..
After having spent over a decade in Python-land myself, I've learned that a Framework's ease-of-use by developers is vastly more important than any micro-benchmark performance.
When I evaluated Falcon for it's usability in mid-2014 I found it painful when compared to Flask or Bottle.
--
But if benchmarks are your thing, for laughs, I've found some which compare Go / Python / Java etc (hey, at least they are data-driven :) :
https://www.techempower.com/benchmarks/ - here "Falcon" scores below Go, Java, and PHP frameworks.
http://ziutek.github.io/web_bench/
https://medium.com/@tschundeee/express-vs-flask-vs-go-acc087...
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.
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.."
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)
The GP shouldn't have included that dig, but this comment would also be strictly better without the first sentence.
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.
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.
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.
Wikimedia had a lot of success migrating to HHVM. They reported a nice speedup when editing a wikipedia page.
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...
Most of the TechEmpower entries are user submitted; If you feel this is the case you should submit one...
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.
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!
Would be nice to see them on https://www.techempower.com/benchmarks/#section=data-r9&hw=p...
The main benefit for me, and the reason why I chose Falcon over other frameworks, is that Falcon is entirely designed around the task of creating REST APIs. You wouldn't use it to create a blog or news site or whatever. You would perhaps use it to create an API backend for any of those though.
This makes it light-weight, and also opens the possibility for some design decisions that would not work in a more general purpose type of framework.
In that regard, Falcon is definitely more opinionated than other frameworks (it's opinion being that you should build REST APIs), but in others, such as choice of response encoder, storage et c, it's not.
I've used Django and Pecan in the past, and both are much more full featured (Django by a couple orders of magnitude), so it's not really clear to me which I'd use for a large project. For something quick and dirty, Falcon seems like a reasonable bet.
This looks interesting, but I'm not well versed at evaluating a new web framework. I've built a few projects in Django, and I have a basic understanding of how I'd go about building a project in Flask. I've never worked on a high-traffic project.
Feature-wise it seems close to Flask. I suspect that Flask is more opinionated than Falcon: it requires the Jinja2 template library and your project may end up with a tight coupling with Flask if you use its blueprint system or don't think through how you use Flask's context variables flask.request and flask.g (Flask tries to be too clever here IMO).
Falcon looks more like a library than a framework to me and its design seems less likely to affect how you structure projects compared to Django in particular but also Flask.
Django/Flask are written for the programmer. I think Falcon is, to a degree, written for the machine (although if you're a systems programmer you may snark at this).
If you are at any point returning HTML from your Falcon project or thinking of serving static content, you should probably not be using Falcon at all. :)
Usually, when you are coding a full API in Django or Flask you find yourself putting additional dependencies in, and this will impact performance and maintainability. Those dependencies won't help you get rid of the "opinion" or "initial purpose" of the frameworks: to build websites, and this will also impact maintainability and performance.
The more important takeaway seems to be that if you use flask, you should probably be using bottlepy instead, as my experience with both indicates that they are otherwise functionally the same.
I'm building a fairly large webapp in Flask and rarely, if at all, use any Flask packages other than the core itself.
That combination is more flexible and productive for me than Flask.
(also, I already have a nice template for bigger projects: https://github.com/rcarmo/ink-bottle)
---
Many frameworks max out at serving simple "hello world" requests at a few thousand req/sec, while Falcon can easily serve many more on the same hardware.
---
Looking at a sibling post it seems like you are just not aware that in many countries , is the decimal separator.
Event-driven processing is much like cooperative multitasking from the Windows 3.1 days. It only works well if every part of the machinery behaves properly and predictively.