# Sanicの実行
Sanicには、独自の内部Webサーバが付属しています。ほとんどの状況では、これがデプロイメントに適した方法です。さらに、Sanicは、ASGI対応ウェブサーバーにバンドルされたASGIアプリとして、またはgunicornを使用してデプロイすることもできます。
# Sanicサーバー
sanic.Sanic
の場合、次のキーワード引数を使用してrunメソッドを呼び出すことができます。
Parameter | Default | Description |
---|---|---|
host | "127.0.0.1" | サーバーをホストするアドレス。 |
port | 8000 | サーバをホストするポート。 |
unix | None | サーバをホストするUnixソケット名 (TCPではありません) |
debug | False | デバッグ出力をイネーブルにします (サーバの速度が低下します) |
ssl | None | workersのSSL暗号化のためのSSLContext。 |
sock | None | サーバーがからの接続を受け入れるためのソケット。 |
workers | 1 | 作成するworkersもしくはprocessの数 |
loop | None | 非同期互換イベントループ。何も指定しないのであれば、独自のイベントループが作成されます |
protocol | HttpProtocol | asyncio.protocolのサブクラス。 |
access_log | True | 要求の処理でログオンを有効にします (サーバの処理速度が大幅に低下します) 。 |
上記の例では、パフォーマンスを向上させるためにアクセスログをオフにしました。
# server.py
app = Sanic("My App")
app.run(host='0.0.0.0', port=1337, access_log=False)
app.run(...)
を持つPythonスクリプトを実行します。
python server.py
# Workers
デフォルトでは、Sanicは1つのCPUコアだけを使用してメインプロセスをリッスンします。具体的には、run引数にworkersの数を指定します。
app.run(host='0.0.0.0', port=1337, workers=4)
Sanicは自動的に複数のプロセスを起動し、それらの間でトラフィックをルーティングする。使用可能なプロセッサと同じ数のworkersを推奨します。
NEW in v21.12
CPUの性能を最大限に引き出す最も簡単な方法は、 fast
オプションを使用することです。これは、システムの制約を考慮して、自動的に最大数のワーカーを実行します。
app.run(host='0.0.0.0', port=1337, fast=True)
$ sanic server:app --host=0.0.0.0 --port=1337 --fast
古いバージョンのSanicで fast
オプションがない場合、LinuxベースのOSでよくある確認方法を試してみてください。。
$ nproc
Or, let Python do it:
import multiprocessing
workers = multiprocessing.cpu_count()
app.run(..., workers=workers)
# viaコマンドの実行
# Sanic CLI
コマンドラインから起動できるシンプルなCLIも用意されています。
たとえば、server.py
という名前のファイルでアプリケーションとしてSanicを初期化した場合、次のようにサーバを実行できます。
sanic server.app --host=0.0.0.0 --port=1337 --workers=4
すべてのオプションを表示するには、sanic --help
を使用します。
$ sanic --help
usage: sanic [-h] [--version] [--factory] [-s] [-H HOST] [-p PORT] [-u UNIX] [--cert CERT] [--key KEY] [--tls DIR] [--tls-strict-host]
[-w WORKERS | --fast] [--access-logs | --no-access-logs] [--debug] [-d] [-r] [-R PATH] [--motd | --no-motd] [-v]
[--noisy-exceptions | --no-noisy-exceptions]
module
▄███ █████ ██ ▄█▄ ██ █ █ ▄██████████
██ █ █ █ ██ █ █ ██
▀███████ ███▄ ▀ █ █ ██ ▄ █ ██
██ █████████ █ ██ █ █ ▄▄
████ ████████▀ █ █ █ ██ █ ▀██ ███████
To start running a Sanic application, provide a path to the module, where
app is a Sanic() instance:
$ sanic path.to.server:app
Or, a path to a callable that returns a Sanic() instance:
$ sanic path.to.factory:create_app --factory
Or, a path to a directory to run as a simple HTTP server:
$ sanic ./path/to/static --simple
Required
========
Positional:
module Path to your Sanic app. Example: path.to.server:app
If running a Simple Server, path to directory to serve. Example: ./
Optional
========
General:
-h, --help show this help message and exit
--version show program's version number and exit
Application:
--factory Treat app as an application factory, i.e. a () -> <Sanic app> callable
-s, --simple Run Sanic as a Simple Server, and serve the contents of a directory
(module arg should be a path)
Socket binding:
-H HOST, --host HOST Host address [default 127.0.0.1]
-p PORT, --port PORT Port to serve on [default 8000]
-u UNIX, --unix UNIX location of unix socket
TLS certificate:
--cert CERT Location of fullchain.pem, bundle.crt or equivalent
--key KEY Location of privkey.pem or equivalent .key file
--tls DIR TLS certificate folder with fullchain.pem and privkey.pem
May be specified multiple times to choose multiple certificates
--tls-strict-host Only allow clients that send an SNI matching server certs
Worker:
-w WORKERS, --workers WORKERS Number of worker processes [default 1]
--fast Set the number of workers to max allowed
--access-logs Display access logs
--no-access-logs No display access logs
Development:
--debug Run the server in debug mode
-d, --dev Currently is an alias for --debug. But starting in v22.3,
--debug will no longer automatically trigger auto_restart.
However, --dev will continue, effectively making it the
same as debug + auto_reload.
-r, --reload, --auto-reload Watch source directory for file changes and reload on changes
-R PATH, --reload-dir PATH Extra directories to watch and reload on changes
Output:
--motd Show the startup display
--no-motd No show the startup display
-v, --verbosity Control logging noise, eg. -vv or --verbosity=2 [default 0]
--noisy-exceptions Output stack traces for all exceptions
--no-noisy-exceptions No output stack traces for all exceptions
# モジュールとして
モジュールとして直接呼び出すこともできます。
python -m sanic server.app --host=0.0.0.0 --port=1337 --workers=4
FYI
どちらの方法(CLIまたはモジュール)でも、Pythonファイルのapp.run()
を呼び出さないでください。もしも実行する場合は、インタプリタによって直接実行される場合にのみ実行されるようにラップしてください。
if __name__ == '__main__':
app.run(host='0.0.0.0', port=1337, workers=4)
# Sanicシンプルサーバー
提供する必要がある静的ファイルのディレクトリだけがある場合もあります。これは特に、localhostサーバーを素早く立ち上げる場合に便利です。SanicにはSimple Serverが付属しており、ディレクトリを指定するだけです。
sanic ./path/to/dir --simple
自動リロードと組み合わせることもできます。
sanic ./path/to/dir --simple --reload --reload-dir=./path/to/dir
# ASGI
SanicもASGIに準拠しています。つまり、任意のASGI Webサーバを使用してSanicを実行できます。ASGIの3つの主要な実装は、Daphne (opens new window),Uvicorn (opens new window),とHypercorn (opens new window)です。
実行方法は次のようになります。 ※適切な実行方法についてはドキュメントを参照してください。
daphne myapp:app
uvicorn myapp:app
hypercorn myapp:app
ASGIを使用する際には、次の点に注意してください。
- Sanic Webサーバを使用する場合、websocketsは
websockets
パッケージを使用して実行されますが。ASGIモードでは、websocketsはASGIサーバで管理されるため、このパッケージは必要ありません。 - ASGIライフスパンプロトコルは、スタートアップとシャットダウンの2つのサーバイベントだけをサポートします。Sanicには、起動前、起動後、シャットダウン前、シャットダウン後の4つがあります。したがって、ASGIモードでは、スタートアップイベントとシャットダウンイベントは連続して実行され、実際にはサーバプロセスの開始と終了の前後では実行されません(なぜなら現在、ASGIサーバによって制御されているためです)。したがって、
after_server_start
およびbefore_server_stop
を使用することをお薦めします。
# Trio
SanicはTrio上での実行を実験的にサポートしています。
hypercorn -k trio myapp:app
# Gunicorn
Gunicorn (opens new window)("Green Unicorn")は、UNIXベースのオペレーティング・システム用のWSGI HTTP Serverです。これはRubyのUnicornプロジェクトから移植されたフォーク前のworkerモデルです。
GunicornでSanicアプリケーションを実行するには、特殊なsanic.worker.GunicornWorker
を実行する必要があります:
gunicorn myapp:app --bind 0.0.0.0:1337 --worker-class sanic.worker.GunicornWorker
アプリケーションでメモリリークが発生した場合、Gunicornを設定して、指定した数のリクエストを処理したあとでワーカーを正常に再起動できます。これは、メモリリークの影響を制限するのに役立つ便利な方法です。
詳細については、Gunicorn Docs (opens new window) を参照してください。
WARNING
gunicorn
経由でSanicを実行すると、async/await
のパフォーマンス上の利点の多くを失うことになります。慎重に検討してから選択してください。Gunicornには多くの設定オプションが用意されていますが、Sanicを最速で動作させるには最適な選択肢ではありません。
# パフォーマンスに関する考慮事項
本番環境で実行する場合は、debug
を必ずオフにしてください。
app.run(..., debug=False)
また、access_log
をオフにすると、Sanicは最も高速に動作します。
それでもアクセスログが必要だが、このパフォーマンス向上を享受したい場合は、Nginxをプロキシとして使用すればアクセスログを処理できます。Pythonが処理できるものよりもはるかに高速になります。
app.run(..., access_log=False)