Does anyone have experience running Flask at scale? I used it once, for a small internal reporting service, and was shocked to find that it was designed to process only a single request at a time, per process. Is this a problem in the real world, or do decent caching rules and query design render it a non issue?
What do flask apps do when they want a live connection to the client, or need to serve a heavy (slow) request? Communicate with a Node websocket server over a queue, and share a database?
I don't mean to disparage Flask. Their goal is to make it simple to stand up site with minimal boilerplate or bloat, and they succeeded at that.
You would typically use something like nginx as a proxy, in conjunction with uwsgi for managing a number of workers, and then offload slow operations to a task queue via redis or something similar. Caching obviously helps if it's applicable and it's also easy to expand to multiple servers with a load balancer. Websockets are a little bit more complicated but definitely possible.
As a side note, the synchronous request processing is more a consequence of Python rather than flask itself. I've personally found that I build more scalable things in Python, compared to something like node, because it lends itself to scalable architecture decisions. You can do a lot of things in node that are super convenient when you have a single server but that require major changes when you expand.
> I've personally found that I build more scalable things in Python, compared to something like node, because it lends itself to scalable architecture decisions. You can do a lot of things in node that are super convenient when you have a single server but that require major changes when you expand.
So, move expensive operations outside of the web processes. Looks like the Flask community has worked out good ways of doing that. Seems legit, answers my question :)
If you want async, use gevent or other async implementation and you'll get ~same as node. If you want parallellism, you'll need multiple processes. Every framework in whatever language should move expensive operations outside of request-response.
We use flask backed by apache mod_wsgi running in containers or VMs at work for our micro Services and it's quite performant. I've run stress tests with this setup using freeBSDs siege command (awesome btw) and 1000+ concurrency and it ran without a hiccup.
I can't say at what level it would break, but I'm confident it would perform as well as django (and it's designed to be thread safe so assuming your following the 12factor app principles And use the process model/attached storage for persistence running elsewhere, you can run multiple threads, apache vhost multi threading notwithstanding.
flasks builtin web server is for debug/development use. Run your flask apps under gunicorn, twisted web or any of the other supported servers in production.
Yeah, I was running it under gunicorn. But that still leaves you with a small number of concurrent connections. If you want to have long connections, for something like long polling or websockets, then being limited to one request per CPU core seems a little sketchy.
Mind you, it could just be that I take high concurrency for granted. I build most web stuff on Node or Clojure, but now that I think about it, apps that require long quiet connections are actually not the norm.
Are you imagine this scenario or you are actually using Flask for long polling? What's your Flask websocket setup looks like?
FYI Flask internal does not stop you from using thousands of threads of greenlets to process concurrency. And web request-response model is embarrassingly parallel on multi-core. Just spawn one worker per core.
For a simple API service if you can not handle 3K rps per Flask instance you are doing it wrong.
I have used Flask at significant scale for REST api requests.
I haven't done web sockets with it - what work I've done with sockets has been in Node.
For building REST apis, it doesn't get easier, IMO. It's very straightforward, it scales well, and it's simplicity makes troubleshooting a reasonable task.
It's appropriateness for slow requests may be questionable, but before spending too much time on a more robust solution it's worth looking into why requests are slow in the first place. Cacheing, message queues, etc. are easy solutions to implement. Data store optimization is generally a quick and easy win that should be done regardless. When it gets to the point where python is the limiting factor it's easy to replace because the client facing front end is generally a proxy.
I run some flask microservices and the key has been to use gunicorn and nginx. It scales up very well. Its not as quick as some other Go microservices I have but Python has an advantage in terms of libraries for my use case. Flask is simple and that helps to keel things under control.
IIRC, flask deploys straight to AWS's elastic beanstalk (gunicorn) with minimal configuration, I even think it's given as an example in EB's docs. I've deployed an EB hosted flask instance (2 ec2 instances behind a load balancer with zero issues) in production.
Nobody ever uses the built-in Flask server for production. The common deployment pattern is to load the Flask app into a WSGI or asyncio serve, which will then handle requests with scalable threading/process models.
Look into uwsgi or gunicorn, and you'll never look back :)
The problem is not Flask. Try to understand the technologies you are working with. If you cannot make Flask work for you chances are you won't be able to make it work with aiohttp/whatever.
Flask is used in production in sites serving thousands of requests/second.
What do flask apps do when they want a live connection to the client, or need to serve a heavy (slow) request? Communicate with a Node websocket server over a queue, and share a database?
I don't mean to disparage Flask. Their goal is to make it simple to stand up site with minimal boilerplate or bloat, and they succeeded at that.