6 ms·

If performance is that important for your use-case, why are you using python? Wouldn't it be better to use an appropriate tool more suitable for your needs? I

If performance is that important for your use-case, why are you using python? Wouldn't it be better to use an appropriate tool more suitable for your needs? 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/ https://www.techempower.com/benchmarks/ - here "Falcon" scores below Go, Java, and PHP frameworks. http://ziutek.github.io/web_bench/ http://ziutek.github.io/web_bench/ https://medium.com/@tschundeee/express-vs-flask-vs-go-acc0879c2122 https://medium.com/@tschundeee/express-vs-flask-vs-go-acc087...

encoderer 12y ago
There are many reasons I might want a framework that emphasizes speed but am unable or unwilling to abandon Python.
- jaytaylor 12y ago
  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.
  - encoderer 12y ago
    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.."
- kjksf 12y ago
  This comment only shows that you don't understand Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_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)
  - felixgallo 12y ago
    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.
    - dang 12y ago
      > 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.
    - zo1 12y ago
      >"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.
nashequilibrium 12y ago
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.
- ajankovic 12y ago
  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.
calpaterson 12y ago
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.
- voidlogic 12y ago
  >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.
  - spullara 12y ago
    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.
    - ddorian43 12y ago
rcarmo 12y ago
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...
- voidlogic 12y ago
  >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...
  - rcarmo 12y ago
    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...
bliti 12y ago
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.
euphemize 12y ago
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.
- davidp 12y ago
  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.
  - netnichols 12y ago
    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.
- richardolsson 12y ago
  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.
  - euphemize 12y ago
    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!
sebasmagri 12y ago
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.

encoderer 12y ago

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

jaytaylor 12y ago
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.
- encoderer 12y ago
  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.."
kjksf 12y ago
This comment only shows that you don't understand Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_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)
- felixgallo 12y ago
  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.
  - dang 12y ago
    > 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.
  - zo1 12y ago
    >"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.

nashequilibrium 12y ago

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.

ajankovic 12y ago
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.

calpaterson 12y ago

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.

voidlogic 12y ago
>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.
- spullara 12y ago
  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.
  - ddorian43 12y ago

rcarmo 12y ago

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...

voidlogic 12y ago
>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...
- rcarmo 12y ago
  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...

bliti 12y ago

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.

euphemize 12y ago

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.

davidp 12y ago
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.
- netnichols 12y ago
  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.
richardolsson 12y ago
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.
- euphemize 12y ago
  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!

sebasmagri 12y ago

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.