eventlet, gevent or simple-websocket?

[fabswt]

For running Flask-SocketIO on gunicorn, the Deployment docs mention three options:

• eventlet
• gevent
• simple-websocket

But which one comes recommended?

My experience with them today hasn't honestly been a lot fun:

• eventlet
  • must be downgraded to 0.30.2 for it to work with gunicorn 20.1.0. The issue has been open for 1.5 years. But even then, in my experience, it does not work with Python 3.10 (which has been out for a year.)
• gevent
  • It's unclear to me from the docs whether gevent-websocket is required. Seemed to work fine on Heroku without gevent-websocket, but I was getting errors locally without it. (dev-prod parity is a mess in Flask.)
  • gevent-websocket hasn't been updated in 5 years and is no longer maintained, so I'd rather not start a project with it.
• Gunicorn's threaded worker + simple-websocket.
  • Ended up switching to it. But it's worth pointing out that I had to uninstall gevent for this to work or else I was getting the dreaded "The WebSocket transport is not available" error.

The docs mention that:

[Gunicorn's threaded worker + simple-websocket] is a particularly good solution for applications that are CPU heavy or are otherwise incompatible with eventlet and gevent use of green threads.

What's the value of green threads and are they preferable to Gunicorn's threaded worker?

I'm running my app on Heroku. Would I be better inspired to choose an option other than gunicorn to start with?

[miguelgrinberg]

First you have to decide if you need an async server (green thread based) or a threaded server is sufficient. Green threads can scale much more efficiently, so they are usually considered a must if the server is going to be busy. In case this isn't clear, green threads (often called greenlets in Python) are somewhat similar to coroutines. Both make it possible to write asynchronous programs. These days most of the asynchronous innovation happens around asyncio, and while both eventlet and gevent are still maintained, they aren't as active as they used to be.

You listed three options, but in reality you have six:

• eventlet
• eventlet + gunicorn in eventlet mode
• gevent + gevent-websocket
• gevent + gevent-websocket + gunicorn in gevent mode
• gevent + uwsgi
• simple-websocket + gunicorn in threaded mode

If your server isn't going to be busy, then the last option should be sufficient, and it is the one that will give you the least trouble. It seems you are trying to list at least one problem for each of the options to make a point, but the one you listed on simple-websocket is not valid, as this is documented behavior. If you don't specify which of these six modes you want to use explicitly by passing the async_mode argument, then Flask-SocketIO picks one for you based on what you have installed. If you don't want to uninstall gevent and eventlet, then add async_mode='threading' when you create your server.

Now for the greenlet options:

The problem that you have with eventlet is an incompatibility with gunicorn. Eventlet is a very complex package that tends to break, so I always recommend not using the latest release. Downgrading to what others have deemed safe is actually a good idea. But if you don't want to do that, you can also drop gunicorn and use eventlet's own web server via socketio.run() or by starting your own web server according to eventlet's WSGI documentation. This should work with any eventlet release old or new (assuming no other bugs in eventlet, of course).

For gevent, gevent-websocket is optional, but if you don't use it then you won't have WebSocket support in your server. Your claim that "dev/prod parity is a mess in Flask" should be directed at the Flask project which are also very responsive. No need to complain about that project here as I cannot help you with that. With gevent, you can also use uWSGI, but that is also a tricky package with a not so great reliability history, so yeah, there aren't great options these days for gevent.

Hope this helps.

[fabswt]

Thank you for the clarifications, they helped a bunch!

FYI (for future generations 😅):

• I ended up going for the "eventlet + gunicorn in eventlet mode" option. Confirmed that this requires eventlet==0.30.2 with gunicorn==20.1.0 on Python 3.9.15. It [eventlet] WILL crash on Python 3.10.
• Decided to avoid the "gunicorn in threaded mode" approach based on your information about greenlets, out of concern with dev-prod parity, and also because I was getting issues running it on Docker locally (issues I didn't have with the other options.)

FYI, about using eventlet without gunicorn, the Flask docs mention this which may be worth keeping in mind:

Prefer using Gunicorn with eventlet workers rather than using eventlet directly. Gunicorn provides a much more configurable and production-tested server.

---

There's no doubt a lot of frustration transpiring from my posts (sorry about that!) I love Python for scripting, but after spending 3 days on questions of deployment and dev-prod parity I'm not exactly enjoying myself 😅

Thanks again for the help! And the library!

[miguelgrinberg]

It WILL crash on Python 3.10.

What is "it" here? I think it would be useful that if you find a situation in which something crashes you report it to the appropriate project, no matter if it is this one or another one. I don't like that you are making passing mention of a crash as if it is a fact of life, without any attempt to find a solution for it.

Edit: after navigating through your posts I now see that here "it" refers to eventlet, which has not one by a few incompatibilities with Python 3.10 still to be addressed, and they are being tracked in the eventlet issue tracker with slow progress.

I was getting issues running it on Docker locally

Same thing. If you are going to complain about a problem, complain in full. A vague reference that is impossible to debug or verify does not help anybody, and in fact creates the impression that this project is unstable, which I definitely do not like.

FYI, about using eventlet without gunicorn, the docs mention this:

Prefer using Gunicorn with eventlet workers rather than using eventlet directly. Gunicorn provides a much more configurable and production-tested server.

This is another confusing statement from you. Sorry to pick on you so much but my docs do not say this, and this isn't a recommendation backed by me or any of my projects. You took this from the Flask documentation, not this project's. I'm not sure how you can give any value to this statement after being forced to downgrade eventlet to make it work with Gunicorn. That is an obvious sign that nobody is concerned about keeping this combination working.

[fabswt]

Hey,
Just trying to go fast.

• "It" crashing referred to eventlet. I updated my post for clarity. The link includes a trace and context.
• For the Docker issue (gunicorn + threaded mode), it was a case of gunicorn crashing with OSError: [Errno 9] Bad file descriptor. Honestly I don't have time to investigate, or incentive to given that threaded mode doesn't seem like the best option for prod and that I now have things running fine with eventlet.
• Edited the part before the quote to mention this was taken from the Flask docs.

They relate to requirements for Flask-SocketIO and not Flask-SocketIO itself.

As far as Flask-SocketIO is concerned, I can only say that having one recommended way of doing things (ideally with dev-prod parity) would have saved me a lot of time. And I take it would save others time as well.

[miguelgrinberg]

I can only say that having one recommended way of doing things

Unfortunately there is no one option that will fit everyone. For a lot of people eventlet and gevent are deal breakers, and the threaded option also presents problems for some for other reasons. If there was a single best way, then I would not have needed to keep looking for more deployment options to offer.

ideally with dev-prod parity

You keep insisting on this, which I do not understand. Flask is a framework that explicitly forbids you to use its web server for production, so you could say that not having this parity you so much want is required unless you are willing to deviate from the development workflow.

On the other side, with Flask-SocketIO you have the option to use the production web servers (gevent or eventlet) also for development, and I have even figured out a way to enable debug mode when you use these. Maybe you can indicate what in the Flask-SocketIO workflow is not equally able to work in dev and prod, because from my point of view Flask has this problem, not Flask-SocketIO.