Projects built with sanic?
jonathansp opened this issue · 26 comments
Question: what do you mean ?
Hi @JordanP, it's important to known if this project could be considered a production-ready solution. Some companies have restrictions on using new frameworks till they become stable. My question is related to author's opinion and people that already use it. If it's not a production-ready project, what would you say that is missing/not good? I'm not planning to use items described on TODO list.
Production ready is a term which so much varies from one company to another, it can be hard for the authors to say "yeah, go ahead now, it's ready". I think you should start by having a good look at the whole code base, then the issue tracker then the frequency and size of new commits (these metrics are not specific to Sanic). You could get a first opinion, in addition to what the authors will reply here.
It says in the meta data (setup.py and pypi) this - Development Status :: 2 - Pre-Alpha.
Perhaps a more concrete, specific question would be: are there any companies / projects out there using Sanic in production? If so, it would be nice to know for how long they've been using it, and what are their loads like. (Note that I am not necessarily asking which companies are using it. I'm fine for that info to stay confidential.)
As someone who is considering using Sanic for a new service (that is part of a paid product), I'd appreciate any anecdotes or data-points from folks production experience with Sanic, or pointers to such anecdotes.
(I'll also add that the 'Development Status' classifier on Python packages isn't very helpful. I couldn't find a definition of what each status is supposed to mean, and it appears that different people are using the same status to mean different things. For example, Flask is labeled as 'Development Status :: 4 - Beta', and yet I am personally aware of several companies that use it in production.)
Hello,
We are using it in our company, mainly for asynchronous push notifications. But the internal API's are not stable yet, some things are messy #381. But we like to be on the edge, hence it works and it keeps us developers happy and still achieve what we want. So I guess depending on who will implement your code and how much they are willing to deal with breaking changes, in our personal experience, can say sanic is production ready. 😇
We are actually using it in production for big companies in Brazil, where the Sanic application exchanges the messages between our ML algorithms and other APIs. Since it's a very simple application, we didn't have any issue running Sanic.
But actually I'm migrating to Python 2.7 and Flask to use AWS Lambda for this task in the next weeks (we are a startup, and don't have someone to keep the deployments very stable on Kubernetes).
Maybe it makes sense to add a list of companies that are using it? If there are a few to start that would be willing to name themselves it would be nice to add it as a section to the docs in my opinion.
@r0fls I agree that it would be nice, but I also can understand that not every company is comfortable speaking publicly about what's in their stack. 😄
@anaulin Although I do not consider it production ready because it's a young project I'm using it since last month under a considerable load... so far no issues.
watching
If you plan on using Sanic in production, do not use Sanic's multiprocessing code at all.
Instead, rely on supervisord or circus to start and keep multiple web server instances alive. You can configure such a daemon to periodically check on the health of each instance with an HTTP request and restart it when, not if it goes bad, for all web servers eventually become unstable after some number of requests for various reasons including memory leaks.
In fact, Instagram disables garbage collection entirely (gc.set_threshold(0)) and uses a supervisor to destroy and restart the entire Python process after it reaches a set memory usage threshold.
https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172#.ovixdthq8
In essence, proper management of processes is in a way more important than the operation of the processes themselves.
@nszceta I'm using Sanic multiprocessing code (as well some other processes created by my app itself) in production for months without issues. It's not a complex API but I believe under 7k requests/sec if there is something wrong it'll show up quickly.
Creating many different processes behind Nginx/HAProxy not only prevent me from doing inter-process stuff (which actually I use a lot) but also slows me by a significant margin (+15%).
Yes, I'm aware this server will never be as secure/reliable as a battle proven server such as Nginx but sincerely this is not the point neither it helps people build stuff.
I'm very far from the best Python developer in the world but disabling the GC is an """"optimization"""" for those who are on Instagram level of crap or don't have a single idea of how to build software properly.
Happy to hear multiprocessing isn't entirely broken, as I implemented some of it :)
If you are already using a supervisor daemon as you should be anyway in production, then the multiprocessing stuff is simply redundant and another potential point of failure.
@frnkvieira you can spawn multiple instances of the same app on the same machine with a supervisor. Do you have any specific use case which is complicated by using supervisord instead of the multiprocessing logic in Sanic? I pointed out disabling the GC as an example of a deep optimization that is made readily available by using a supervisor daemon. It is just one example of the benefits of running a supervisor. Not only do you have more reliable workers, but optimizations of this sort become simpler to implement should you need them down the line. I have run into a problem several times where Sanic stops responding and needs to be restarted, something which can be done readily with a supervisor daemon monitoring the health of my Sanic workers.
@nszceta Although I don't like supervisor myself I do use Systemd to monitor Sanic processes... My point is: I don't want to bind multiple ports and load balance between them with Nginx because it adds a considerable overhead for me. Also I do have some real-time stats module implemented which is entirely based on the fact Sanic processes are forked instead of complete separated processes as you are telling me to do. Don't get me wrong, it's fine to do as you say but it's not the only way.
@frnkvieira very interesting analysis; where can I learn more about your real time stats module?
We are using Sanic in production, we open-sourced one of it today.
Have a work-in-progress Blog using MDL blog template:
https://github.com/stopspazzing/Sanic-Server-with-MDL-Blog-Template
+1 to create a list of companies that uses Sanic on production.
Once wiki is enabled will be moved there, until then https://github.com/stopspazzing/sanic/wiki/Projects
Editable by all.
Wiki is up: https://github.com/channelcat/sanic/wiki/Projects add all new projects there.
I just shipped https://json-head.now.sh/ using Sanic and wrote up a detailed tutorial about how I build it: https://simonwillison.net/2017/Oct/14/async-python-sanic-now/
Still relevant?