Bjoern: 明確な例を含む通常のドキュメントはありません

申し訳ありませんが、この時点で例から学ぶ必要はありません。 これはWSGIサーバーなので、使用法はかなり自明である必要がありますか？

あなたにとって明らかなことは他の人にとっては明白ではないかもしれません-それが問題であり、経験と知識の違いです。 すべての人が違います。 もちろん、「これは単なるWSGIサーバーです」と言うのは正しいですが、それでも、使用する製品に関するドキュメントがあり、その使用方法が白黒で書かれていると、どれほど素晴らしいかについて同意するでしょう。あなたは使うことができます、そしてどのような場合に失う価値さえありませんか、そして触ると、何が起こっているのか、そしてどこに行くのか想像がつかない、彼の額にぶつかる盲目の子猫のように感じるのはどれほどひどいです。
私はプロジェクトのドキュメンテーションの価値を絶対に認めませんが、確かに「bjoern」である十分に深刻な成熟した製品には、少なくとも形成されたコミュニティとの関係で良いトーンとして必要であると信じています。

同意しました、パッチは大歓迎です！ :)

この時点で例から学ぶ必要があります。

どのような例ですか？

テスト😬

同意しました、パッチは大歓迎です！ :)

@jonashaagパッチを提供するには、十分な能力が必要です。 あなたはおそらく助けることができますか？

あなたの例から、私は次のオプションを推測することができます：

1. シングルスレッド：

import bjoern
from datetime import datetime

HOST = '0.0.0.0'
PORT = 8080

def app(e, s):
    s('200 OK', [])
    return str(datetime.now()).encode('utf-8')

try:
    bjoern.run(app, HOST, PORT)
except KeyboardInterrupt:
    pass

1. 複数のプロセス（＃120も参照）：

import bjoern
import os, signal
from datetime import datetime

HOST = '0.0.0.0'
PORT = 8080
N_WORKERS = 2

worker_pids = []

def app(e, s):
    s('200 OK', [])
    return b'%i: %s' % (
        os.getpid(),
        str(datetime.now()).encode('utf-8')
    )

bjoern.listen(app, HOST, PORT)
for _ in range(N_WORKERS):
    pid = os.fork()
    if pid > 0:  # parent
        worker_pids.append(pid)
    elif pid == 0:  # worker
        try:
            bjoern.run()
        except KeyboardInterrupt:
            pass
        exit()

try:
    for _ in range(N_WORKERS):
        os.wait()
except KeyboardInterrupt:
    for pid in worker_pids:
        os.kill(pid, signal.SIGINT)

複数のスレッド（おそらく「ステアリングの受信」と呼ばれるもの）を実行しても、機能しないようです。

import bjoern
from datetime import datetime
import threading

HOST = '0.0.0.0'
PORT = 8080
N_THREADS = 2

def app(e, s):
    s('200 OK', [])
    return b'%s: %s' % (
        threading.current_thread().name,
        datetime.now()
    )

sock = bjoern.listen(app, HOST, PORT, reuse_port=True)
for i in range(0, N_THREADS):
    t = threading.Thread(target=bjoern.server_run, args=[sock, app])
    t.start()

$ python multiple-threads.py
Assertion failed: ("libev: a signal must not be attached to two different loops", !signals [w->signum - 1].loop || signals [w->signum - 1].loop == loop) (ev.c: ev_signal_start: 4565)
Aborted (core dumped)

そして、私が理解していないことがいくつかあります。

1. 私の理解では、 bjoern効果的に使用するには、アプリケーションコードを非同期にする必要があります。 bjoernは手段を提供しません。 サードパーティのライブラリを使用する必要がありますか？ 何かお勧めはありますか？ bjoernイベントループをそのように再利用しますか？

2. アプリケーションコードが非同期（db、ファイル、ネットワーク）であり、多くの計算（CPU）を行わない場合、 bjoernが適していますか？ つまり、ユースケースは何ですか？ しかし、おそらくそれでも複数のワーカーを実行することが望ましいでしょう。 それ以外の場合は、最大で1つのCPUコアが使用されます。 何かアドバイスはありますか？ CPUコアごとに1人のワーカー？

3. 生産準備はできていますか？

「テスト」を実行しているときに私が見つけたいくつかの問題：

• statsdが機能しません（別のポートのリッスンを開始しません）
• AttributeError: module 'bjoern' has no attribute 'features'
• 一部のテストはPython3では機能しません（ httplibを使用するテスト）

そして、おそらく私の将来の自己のためのメモ：

$ docker run --rm -itv $PWD:/app -w /app alpine sh
/ # apk add build-base libev-dev git python3-dev py3-requests
/ # cd app
/app # git clone https://github.com/jonashaag/bjoern
/app # cd bjoern
/app/bjoern # git submodule update --init
/app/bjoern # python3 setup.py install

もちろん ：）

例1と2は問題ありませんが、次のようになります。

1）例外を無視することはお勧めしません
2）その後os.exec*実行しない場合は、プロセスをフォークすることもお勧めしません。 ユースケースでは機能するかもしれませんが、bjoernとは関係のない理由から、それほど堅牢ではありません。使用している他のライブラリの中には、forkではうまく機能しないものもあります。
3）あなたは誤解したに違いありません。 受信ステアリングは、 SO_REUSEPORT （ bjoern.run(..., reuse_port=True) ）を使用して、同じポートで複数の完全に別個のプロセスを実行することです。 これに同じPythonプロセスを使用することはお勧めしません（フォークなどを使用）が、OSプロセスを完全に分離します。 ご覧のとおり、libevの制限により、スレッドは機能しません。

私の理解では、 bjoern効果的に使用するには、アプリケーションコードを非同期にする必要があります。 bjoernは手段を提供しません。 サードパーティのライブラリを使用する必要がありますか？ 何かお勧めはありますか？ bjoernイベントループをそのように再利用しますか？

はいといいえ。 Bjoernは、結果イテレータ項目を遅延計算することを除いて、アプリケーションを適切に非同期化する方法を提供していません（つまり、コードで計算できるようにするには、多くのyieldステートメントを使用するか、他の方法で記述する必要があります。結果を1つずつ）：

def async_example():
    piece1 = dostuff1()
    yield b""  # or a non-empty intermediate result
    piece2 = dostuff2()
    yield b"". # or a non-empty intermediate result
    piece3 = dostuff3()
    result = combine_pieces(piece1, piece2, piece3)
    yield result

非同期インターフェースを提供しない理由は、99％のWebアプリケーションをプログラミングするのにそれらが良い選択ではないと思うからです。 それらは多くの問題とスパゲッティコードを引き起こし、利点は非常に特定のタイプのアプリケーション（I / Oバウンド+非常に大規模）に限定されます。

ただし、Webサーバーの場合、非同期I / Oを使用することは非常に理にかなっています。たとえば、一部のクライアントが遅い場合でも、ワーカーを追加しなくても要求を処理し続けることができます（そうでない場合、サーバーをブロックしたり、サーバーを占有したりします）。それらのステータスをチェックするためのリソース）。

したがって、bjoernは非同期イベントループを使用して実装されますが、アプリケーションに非同期インターフェイスを提供しません。

アプリケーションコードが非同期（db、ファイル、ネットワーク）であり、多くの計算（CPU）を行わない場合、bjoernが適していますか？ つまり、ユースケースは何ですか？ しかし、おそらくそれでも複数のワーカーを実行することが望ましいでしょう。 それ以外の場合は、最大で1つのCPUコアが使用されます。 何かアドバイスはありますか？ CPUコアごとに1人のワーカー？

これはおそらく、99％のアプリケーションに適度に高速なWebサーバーと同じくらい適しています。 理論的には、この種のワークロードは、非同期インターフェイスを提供するWebサーバーにはるかに適しています。

労働者の数に関する推奨事項はありません。 アプリケーションによって異なります。 コア/スレッドごとに1人のワーカーから始めるのが妥当なようです。

生産準備はできていますか？

わからない。 私はこのプロジェクトを約10年前に、C、ソケット、およびPython CAPIを学ぶ方法として開始しました。 私は複数のプロジェクトで問題なく本番環境で使用しており、他の人も問題なく使用していると思いますが、ほとんどの企業は、uWSGIやgunicornなどの有名で実際に戦闘でテストされたサーバーに固執していると思います（いつでも同じことをすることをお勧めします。）

statsdが機能しません（別のポートのリッスンを開始しません）

statsdはプッシュを使用しません。 クライアントはサーバーにメトリックを送信しますか？

AttributeError：モジュール 'bjoern'には属性 'features'がありません

使用しているバージョンなどで、そのための新しい問題を開くことができますか？

一部のテストはPython3（httplibを使用するテスト）では機能しません

確かに、パッチは大歓迎です:)

Dockerファイルについては、PRを送信すると、Alpineベースのイメージをマスターにマージできます。 :)

例外を無視することはお勧めしません

ここでKeyboardInterrupt意味するのではないと思います。 おそらく、例外によってプロセスがクラッシュしないようにすることをお勧めします。 しかし、 app()で例外を発生させようとしましたが、クラッシュしませんでした。

また、その後os.exec *を実行しない場合は、プロセスをフォークすることはお勧めしません。

さて、それは私たちに与えます：

master.py ：

import bjoern
import signal
import subprocess

N_WORKERS = 2

workers = [subprocess.Popen(['python', 'worker.py']) for i in range(N_WORKERS)]

try:
    for w in workers:
        w.wait()
except KeyboardInterrupt:
    pass

worker.py ：

import os
from datetime import datetime

import bjoern

HOST = '0.0.0.0'
PORT = 8080

def app(e, s):
    print('%s: %s' % (datetime.now(), e['PATH_INFO']))
    s('200 OK', [])
    return b'%i: %s\n' % (
        os.getpid(),
        str(datetime.now()).encode('utf-8')
    )

try:
    bjoern.run(app, HOST, PORT, reuse_port=True)
except KeyboardInterrupt:
    pass

しかし、今、プロセスが終了するのをどのように待つのですか？ おそらく定期的にpoll()になる可能性がありますが、もっと良い方法があるのではないでしょうか。

非同期インターフェースを提供しない理由は、99％のWebアプリケーションをプログラミングするのにそれらが良い選択ではないと思うからです。

明確にするために、私は最近まで並行性をあまり気にしませんでした。 どういうわけかうまくいきました。 私が知っているのは、それが1つのスレッドまたはプロセスだけではなかったということだけです。

つまり、 bjoernは、 app()関数はクリティカルセクションのようなものであり、前の関数が終了するまで呼び出されないということですか？ そして、99％のWebアプリケーションでは、このような制約は大きな影響を与えませんか？ 明確にするために、私は戦いを始めるつもりはありません。 bjoern下で走っているときに何が大丈夫かを知りたいだけです。

サイトは通常何をしますか？ 彼らはデータベースに問い合わせます。 リモートサービス（httpリクエスト）と通信します。 画像のトリミング/サイズ変更。これはおそらくCPUに依存する種類の負荷です。 最近、私があまり知らないWebソケットもあります。 これらはおそらくここで最も関連性の高い活動です。

そして、あなたはこれらすべてがbjeorn大丈夫だと思いますか？ つまり、長時間実行されるクエリがある場合、複数のワーカーを実行しないと、Webサーバー全体がブロックされます。 サイトが通信するサードパーティのサーバーが応答を遅くし始めた場合も同じことが起こります。 したがって、単一のプロセスを実行することは、問題を求めるように聞こえます。 次に、一部のWebサーバーは、複数のワーカースレッドを実行する複数のワーカープロセスを実行できます。 これはおそらく、 n_processes * n_threadsワーカープロセスを実行するよりもメモリ効率が高くなります。 また、負荷が大きくなると（負荷に合わせて）、追加のワーカースレッド（または追加のワーカープロセス）を生成できるものもあります。 bjoernには方法があるかもしれませんが、...頭のてっぺんから...何も思い浮かびません。

これはあなたの答えを変えますか？ いずれにせよ、静的ファイルを提供するには、おそらくリバースプロキシ（ nginx ？）が必要ですか？

statsdはプッシュを使用しません。 クライアントはサーバーにメトリックを送信しますか？

実際、私はstatsdについて何も知りません。 statsd={'host': '127.0.0.1', 'port': 8888, ...}見て、テストを開始し、ポート8888で何もリッスンしていないのを見て、 BJOERN_WANT_STATSD=yesでビルドしましたが、効果はありませんでした。 私の悪い、おそらく。

ここでKeyboardInterrupt意味するのではないと思います

申し訳ありませんが、これはまさに私が意味したことなので、より具体的にする必要があります:)

さて、それは私たちに与えます：[...]
しかし、今、プロセスが終了するのをどのように待つのですか？ おそらく定期的にpoll()になる可能性がありますが、もっと良い方法があるのではないでしょうか。

これは問題ないように見えますが、通常、これらのプロセスを処理する適切なプロセスマネージャーが必要です。 他のアプリケーションプロセスも処理するプロセスマネージャーを使用するだけでかまいません。まだ使用していない場合は、supervisord、systemdなどを使用できます。

前のものが終了するまで呼び出されません

はい！

つまり、長時間実行されるクエリがある場合、複数のワーカーを実行しないと、Webサーバー全体がブロックされます。 サイトが通信するサードパーティのサーバーが応答を遅くし始めた場合も同じことが起こります。 したがって、単一のプロセスを実行することは、問題を求めるように聞こえます。 次に、一部のWebサーバーは、複数のワーカースレッドを実行する複数のワーカープロセスを実行できます。 これはおそらく、 n_processes * n_threadsワーカープロセスを実行するよりもメモリ効率が高くなります。 また、負荷が大きくなると（負荷に合わせて）、追加のワーカースレッド（または追加のワーカープロセス）を生成できるものもあります。

あなたが言っていることは正しいです。 具体的には、ほとんどの場合、個別のプロセスよりもスレッドを使用する方がメモリ効率が高くなります（ただし、forkを使用するとメモリをいくらか節約できますが、forkには他の欠点があります）。 したがって、アプリケーションのメモリフットプリントが大きい場合は、別のサーバーを使用したほうがよいでしょう。 エンジニアリング時間を大幅に節約するためにメモリを追加購入できる場合を除きます:)

「外部サービスを待つ」という点については、実際の意味は限られていると思います。 実際には、外部サービスには容量制限があり（たとえば、1秒あたりに処理される要求）、アプリケーションを構築するテクノロジを評価するときに、それを考慮に入れる必要があります。 したがって、完全に非同期のアプリケーションを使用すると、外部サービスに対して1秒あたりより多くのリクエストを行うことができますが（理論的には）、サービスの応答がこれ以上速くなることはなく、完了までの合計時間は同じままです。 リクエストはサービスのキューに蓄積され、サービス全体が過負荷になる可能性があります。 背圧が不足し

質問は; ボトルネックはどこにありますか？ アプリケーションを遅くする原因は何ですか？ 外部サービスを待っていますか？ 次に、それらのサービスを最適化します。 アプリケーションが実行できる同時リクエストの数は限られていますか？ 次に、それを最適化します（たとえば、非同期に切り替えることによって）。

非同期プログラミングでは、これらの非同期パラダイムを使用するだけで、無制限の同時実行性を「無料」で取得できるように見える場合があります。 しかし、フリーランチはありません。 非同期プログラミングには、同期プログラミングを行うときに対処する必要のない他の多くの欠点があります。 最終的に問題となるのは、特定のアプリケーションで何が機能するか、そしてエンジニアリング時間とサーバーコストに費やしたお金をどれだけ重視するかです。 個人的には、非同期プログラミングはせいぜい特定のパフォーマンスの問題を解決するという経験があり、ほとんどのアプリケーションコードに使用することはお勧めしません。

いずれにせよ、静的ファイルを提供するには、おそらくリバースプロキシ（ nginx ？）が必要ですか？

WSGIアプリケーションがwsgi.file_wrapperサポートしている場合は、bjoernを使用して静的ファイルを提供できます（ほとんどのフレームワークはサポートしています）。 ただし、大規模な本番アプリケーションの場合は、どのような場合でもリバースプロキシを使用することを常にお勧めします。

bjoernを実行する方法を改善し続けることを計画しています。 今のところdockerです。 コメントは大歓迎です。

docker-compose.yml ：

version: '3'

x-defaults: &defaults
  restart: always
  logging:
    options:
      max-size: 50m
      max-file: '5'

services:
  app:
    <<: *defaults
    image: python:alpine
    command: python /server.py
    volumes:
      - ./server.py:/server.py
    deploy:
      replicas: 2

  # nginx:
  #   <<: *defaults
  #   image: nginx:alpine
  #   volumes:
  #     - ./nginx.conf:/etc/nginx/conf.d/default.conf
  #   ports:
  #     - 8888:80

  haproxy:
    <<: *defaults
    image: haproxy:alpine
    ports:
      - 8888:80
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg

nginx.conf ：

server {
    location / {
        proxy_pass http://app:8080;
    }
}

server.py ：

#!/usr/bin/env python
import socket
from http.server import HTTPServer, BaseHTTPRequestHandler

class MyHTTPRequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(socket.gethostname().encode('ascii'))

httpd = HTTPServer(('', 8080), MyHTTPRequestHandler)
httpd.serve_forever()

haproxy.cfg ：

listen in
    # mode http
    bind :80
    server-template srv 2 app:8080 check # resolvers docker_resolver
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

# resolvers docker_resolver
#     nameserver dns 127.0.0.11:53

またはbjoern ：

docker-compose.yml ：

...
  app:
    <<: *defaults
    build: .
    command: python /server.py
    volumes:
      - ./server.py:/server.py
    deploy:
      replicas: 2
...

Dockerfile ：

FROM python:alpine
ENV PYTHONUNBUFFERED 1
RUN apk add --no-cache build-base libev-dev \
    && pip install bjoern

server.py ：

import os
import socket
from datetime import datetime

import bjoern

HOST = '0.0.0.0'
PORT = 8080

def app(e, s):
    print('%s - - [%s] "%s %s %s" 200 -' % (
        e['REMOTE_ADDR'],
        datetime.now(),
        e['REQUEST_METHOD'],
        e['PATH_INFO'],
        e['SERVER_PROTOCOL']))
    s('200 OK', [])
    return socket.gethostname().encode('utf-8')

print('starting bjoern (%s:%s)' % (HOST, PORT))
bjoern.run(app, HOST, PORT)

免責事項。 haproxyを使うのは初めてです。 構成が最適でない可能性があります。

例外を無視することはお勧めしません

ここでKeyboardInterruptを意味するのではないと思います

申し訳ありませんが、これはまさに私が意味したことなので、より具体的にする必要があります:)

ああ、それではKeyboardInterruptを無視することの何が問題になっていますか？ サーバーを停止したときにスタックトレースが表示されないように、追加するか、そのままにしておきました。

アプリケーションが実行できる同時リクエストの数は限られていますか？ 次に、それを最適化します（たとえば、非同期に切り替えることによって）。

それをどのように確認すればよいのでしょうか...任意の時点でbjoernによってキューに入れられているリクエストの数を確認する方法はありますか？ nginx ？ 何か提案してもらえますか？

bjoernおよびsystemd

server.py ：

import os
from datetime import datetime
import systemd.daemon

import bjoern

HOST = '0.0.0.0'
PORT = 8080

def app(e, s):
    print('%s: %s' % (datetime.now(), e['PATH_INFO']))
    s('200 OK', [])
    return b'%i: %s\n' % (
        os.getpid(),
        str(datetime.now()).encode('utf-8')
    )

listen_fds = systemd.daemon.listen_fds()
if listen_fds:
    bjoern.server_run(listen_fds[0], app)
else:
    bjoern.run(app, HOST, PORT)

/etc/systemd/system/bjoern.service ：

[Unit]
Description=Bjoern server

[Service]
WorkingDirectory=/path/to/prj/root
ExecStart=/path/to/prj/root/env/bin/python server.py
Restart=always

/etc/systemd/system/bjoern.socket ：

[Unit]
Description=Socket for the Bjoern server

[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target

ここでは、通常の実行時（ systemctl start ）とソケットのアクティブ化の結果の両方で機能するようにします。 後者の場合、明らかにソケットを開始する必要があります。

$ python -m venv env
$ ./env/bin/pip install systemd-python
$ systemctl start bjoern.socket
$ curl -sS localhost:8080

それを機能させる方法があるようです。つまり、CGIモード（ Accept=yes 、接続ごとの新しいプロセス）です。 しかし、その良いユースケースを考えると何も思い浮かびません。 どちらの場合も適切ではないようです（何らかの理由でパフォーマンスを犠牲にする意思がない限り）。 そして、まあ、私はそれがたった1つのリクエストを処理するようにする方法さえ知りません。 したがって、この場合の指示はありません。

そして、3番目のオプションであるテンプレートユニットファイルがあります。 どちらを採用することもできますが、それがこのタスクに適しているかどうかはわかりません。 その結果、全体として制御できない個別のサービスがいくつかあります。 しかし、とにかく私たちが持っているテンプレートユニットファイルでは（ソケットのアクティブ化はなく、 reuse_port=True部分に注意してください）：

server.py ：

import os
from datetime import datetime

import bjoern

HOST = '0.0.0.0'
PORT = 8080

def app(e, s):
    print('%s: %s' % (datetime.now(), e['PATH_INFO']))
    s('200 OK', [])
    return b'%i: %s\n' % (
        os.getpid(),
        str(datetime.now()).encode('utf-8')
    )

bjoern.run(app, HOST, PORT, reuse_port=True)

/etc/systemd/system/[email protected] ：

[Unit]
Description=Bjoern server

[Service]
WorkingDirectory=/path/to/prj/root
ExecStart=/path/to/prj/root/env/bin/python server.py
Restart=always

[Install]
WantedBy=multi-user.target

$ systemctl start bjoern<strong i="37">@1</strong>
$ systemctl start bjoern<strong i="38">@2</strong>
$ curl -sS localhost:8080

アプリケーションが実行できる同時リクエストの数は限られていますか？ 次に、それを最適化します（たとえば、非同期に切り替えることによって）。

どうやってチェックしたらいいのかな…

最も簡単な方法は、1つのインスタンスから始めて、1秒あたりに処理できるリクエストの数を確認し、次に2つのインスタンスなどを確認して、それ以上の改善が見られなくなるようにすることだと思います。 また、各テストのメモリとCPUの使用率を確認してください。 メモリまたはCPUを飽和させることができる場合は、より大きなマシン、またはより多くのマシンが必要です。あるいは、リソースが正確にどこで使用されているかを把握する必要があります。

ちなみに、展開設定をwikiに自由に追加してください！