-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Production and development modes (default workers) #2169
Comments
This lines up with another thought that I had related to some discussions recently, and that is to give more teeth to debug mode. We are pretty light on debug logs, and that could probably be turned up a bit. As for default With that said, I do like the idea of rethinking our defaults, the project has grown and matured a lot and we have not changed these. As for production mode by default... 🤔 My reservation on that is it may be a bit confusing for someone kicking the tires. This could be remedied with an example that explicitly enables debug mode, but it is worth mentioning. The other thing that might be helpful here is a little more information in the startup logs. Fairly recently I added a little more:
|
I would be opposed to defaulting to more than one worker due simply to the fact that workers cannot spawn child processes due to the daemonic nature. Even doing a Setting this default would be a breaking change to any applications currently using child processes. |
I agree with @ahopkins and @eric-spitler, we should definitely default to a single worker even in Production mode. Multi-workers should always be something a user specifically enables manually, for the reasons outlined above. And just for some context, around why sanic has such weird defaults to begin with. Its because Sanic's Of course Sanic has evolved a lot since then, and moved away from its Flask-mimic heritage, so I agree we're overdue to change the defaults. On a personal note, I'm not a fan of setting
For those reasons, I always use |
What if we add a |
Okay, looks like there are legitimate concerns about multiple workers by default. Can we still disable access logs by default in How about this: Revert |
This is sounding much more the direction I'd like to go. Several config options to be done separately, and then bundled together with smart defaults.
👍 to --dev and --fast (-D and -F)? |
The names are short enough without single-letter versions IMO. Also worth noting is that these two are not contradictory modes since |
I think it does. "fast" should be disable access logs and enable max workers (unless you specifically enable them separately), and set the sanic loggers appropriately. Maybe disable all loggers except the error logger. |
Somewhat related... What about spitting out OS, and platform details along with Sanic installation (this last one I think is in one of the recent PRS I made) at debug startup for easy copy/paste on support queries? |
When checking to see the number of CPUs available can we do an OS check and if the system is Linux then return Explanation: https://docs.python.org/3/library/os.html#os.sched_getaffinity |
That seems reasonable. |
Here is my proposal:
|
Quite many modes, and a lot of differences that are not entirely obvious. The table also does not say whether tracebacks are shown on error pages (debug mode can be a security risk). |
Not really.... it is three modes: debug/default/prod, only one of which is new: --dev and --fast are more like modifiers (exactly as your proposal). The goal here is to thread the line between adding functionality and not breaking anything (yet).
Yes, existing tracebacks would not change. I will update the table to reflect that |
While it is possible to specify these individual features by hand, I would rather see a simple mode flag to get sensible defaults:
Sanic server by default runs with a single worker process and doesn't enable features that would be useful in development. Many people accidentally use these default settings for benchmarking and production but the performance is poor due to lack of multiprocessing and due to logging if
app.run
was used. The debug mode cannot be enabled by default because running it in production is a potential security risk, so making the production mode the new default seems a better option.Notably the reloader setting by default already follows the debug flag. I believe this should done with the access log setting too (currently
app.run(debug=True)
andapp.run(debug=False)
both enable access logs, whilesanic
CLI disables logs irregardless of the--debug
flag). Alike, the number of workers could depend on the debug flag, keeping the single worker default in debug mode, but using the number of CPUs by default.By these changes we get production mode by default, and adding
debug=True
orsanic --debug
would accomplish full switch of all relevant settings into development mode.This is potentially a breaking change with application servers that run multiple Sanic instances on different ports with the intention that each Sanic instance stays a single process. If this is a problem, specifying workers=1 in these installs is a simple and backwards-compatible fix.
Relevant
app.run
parts shown with changes:I'd like to hear your thoughts before implementing this. This can probably be done better, or perhaps I overlooked something.
The text was updated successfully, but these errors were encountered: