Falcon is a high-performance Python Web framework(falconframework.org)
falconframework.org
Falcon is a high-performance Python Web framework
http://falconframework.org/
77 comments
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.
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.
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.."
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)
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.
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.
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.
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.
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.
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.
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.
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...
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...
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...
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.
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.
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 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.
The website is saying how good the framework is but I really miss seeing right on the homepage how code written using this framework looks like. Flask's website is really good at this, for instance.
Agreed; their README is better which includes sample code:
https://github.com/racker/falcon/blob/master/README.md
https://github.com/racker/falcon/blob/master/README.md
My first thoughts as well when scanning the homepage.
It should be fixed now.
I'm just wondering if the name is already taken :P slightly different but still same sound
http://www.phalconphp.com/en/
http://www.phalconphp.com/en/
the name is pretty much always already taken
What about when I have auth or any number of middleware and am hitting a cached-object store; do the performance gains continue to stand out? With just a few dict and string operations, their tests showed performance dropped considerably. I'm going to be doing more than that in each request; I'm not going to use this to use Python to serve anything but dynamic content.
Would be nice to see them on https://www.techempower.com/benchmarks/#section=data-r9&hw=p...
Would be nice to see them on https://www.techempower.com/benchmarks/#section=data-r9&hw=p...
I've recently started using Falcon, and also contributed some code to it (e.g. an even faster router which generates and compiles python code representing the URI tree).
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.
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.
Performance is always a factor for me, until IBM finishes that new line of $1.00 servers that don't use electricity and are the size of an atom... in the meantime, we can continue to learn from highly performant libraries and frameworks like this.
The value of Falcon for me is less its performance and more that it it for building REST APIs and does not carry the legacy of trying to support creation of Html front ends, along with all the associated complexity and cruft and dilution.
I welcome any effort that aims to improve performance and the python Web ecosystem. From the code in the tutorials Falcon feels a little un-pythonic. This is not a criticism. But a comparison from my experience with other python frameworks (mainly django and flask). It is unfair to compare mature frameworks with a new one. Though this one feels a bit java-ish. Good? Bad? To me that's good. It's stepping out of the comfort zone a bit. Rather than read purely like the idioms of the language, it seems to aim to read like the process it defines. Something that other frameworks abstract down their own idioms.
I recently used Falcon to hack together a quick email backend for an ajax comments form, and found it really useful. It's super lightweight and was relatively easy to get working with uwsgi/nginx.
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.
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.
Can someone compare this to Django/ Flask? Would building a project with Falcon be similar to building a project with Flask?
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.
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.
As others has already pointed out, the goal of Falcon is to ease the creation of REST APIs and run with the best possible performance.
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.
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.
Their GitHub README includes some examples [0]. It is sort of a hybrid between Django+TastyPie (Object-Oriented API wiring) combined with Flask or Bottle.
[0] https://github.com/racker/falcon#usage
[0] https://github.com/racker/falcon#usage
It's not like Django + TastyPie just because it uses OO. If you are building a service with two or three endpoints, that combo is overkill. “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” comes to mind. It's closer to Flask feature-wise.
Django is much larger with its ORM, template system, admin site, and so on.
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.
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.
Flask likely requires Jinja2 because they're both made by the same team. http://www.pocoo.org/team/#armin-ronacher
iirc, the goal was to minimize memory compaction within the framework in order to boost the number of concurrent requests and speed at which one can address them. This might have reflected in some slightly un-pythonic design choices in order to avoid string literals in the framework code, etc.
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).
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).
Django is a "web framework", for creating web sites. Falcon is a "REST API" framework, for creating APIs following the REST pattern. Flask is less clear (or "opinionated") as to what it should be used for, and would probably fall somewhere in between the other two.
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. :)
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. :)
I normally use bottle and this isn't much of a step of from that, it would seem.
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.
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.
Flask has a much larger pool of community extensions, and in general has more community support and more "batteries included" than Bottle. In my opinion, there is no real reason to use Bottle anymore.
Community extensions are exactly what I dislike about Flask. I want extensibility without custom extensions. I want the framework to be out of the way entirely when I choose additional packages to work with.
then don't use the extensions? Not trying to be snarky, I might be missing something, but does Flask actually make it harder to use additional packages?
Nope. You can use whatever packages you like. Those you've rolled yourself, standard python packages like psycopg2, redis-py etc., Flask community provided packages and anything in between.
I'm building a fairly large webapp in Flask and rarely, if at all, use any Flask packages other than the core itself.
I'm building a fairly large webapp in Flask and rarely, if at all, use any Flask packages other than the core itself.
Hmmm. I get nice templating and very straightforward routing with Bottle. Why shouldn't I use that, especially since I can review the whole codebase in half an hour?
Do you not get that with Flask?
Flask has always struck me as requiring too many plugins. With bottle, I just drop one file into my work dir and I'm off. Toss in Peewee as well (another single file) and I get a decent ORM.
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)
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)
One would think that there's too much competition and enough maturity among Python web frameworks to see such speed gains.
A framework, by definition, must be opinionated. A framework without opinions is just a library.
Wow, is Python3 still that much slower than Python2?
iirc, Python 3.4 saw a strong leap in performance largely related to unicode. Could be wrong but the earlier versions of Python 3 did suffer some slow down.
It also helps that Python2 based web frameworks play a bit fast & loose with the odd ambiguities in the HTTP protocol that Python3 won't let you get away with.
120 req/s is considered fast?
Let me guess... LCD font smoothing on a reasonably high resolution Apple display?
[deleted]
From the linked page under Benefits/Performance section:
---
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.
---
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.
High performance, makes me wonder how it deals with the GIL (global interpreter lock).
That's not really a problem with serving web requests. Usually there isn't a downside to multiprocessing these. I don't know anything about this framework but I assume it is using some sort of non-blocking IO which works just about as well as OS threads for web servers. Look at something like Gevent if you are interested in this.
The problem is that sometimes you do need to do some heavy processing while servicing a request, and then you're blocking all other users.
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.
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.
Performance and Python on the same sentence?!?
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...