Bjoern: Linuxでのパフォーマンスの低下

作成日 2020年01月24日  ·  14コメント  ·  ソース: jonashaag/bjoern

こんにちは、
私はいくつかのパフォーマンス結果を集めていますが、BjoernはLinuxよりもmacOSの方がはるかに高速であることがわかりました。

wrkを使用したLinuxベンチマークで8分の1のパフォーマンスが得られます。 これは仕様によるものですか? macOSが推奨されるプラットフォームですか、それとも何か問題がありますか?

最も参考になるコメント

うーん、いくつかのベンチマークを実行しただけです。2つのvCPUを備えた完全に最適化されていないLinuxサーバーは問題ないようです。

import bjoern

def app(env,sr):
    sr('200 ok', [('content-length','0')])
    return ''

bjoern.run(app, 'localhost', 8888, reuse_port=1)
$ venv/wrk/wrk -t12 -c400 -d10s http://127.0.0.1:8888/index.html
Running 10s test @ http://127.0.0.1:8888/index.html
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.76ms    5.45ms 139.52ms   84.60%
    Req/Sec     3.93k     1.08k   19.63k    80.95%
  470512 requests in 10.09s, 27.82MB read
Requests/sec:  46628.11
Transfer/sec:      2.76MB
$ venv/wrk/wrk -t4 -c20 -d10s http://127.0.0.1:8888/index.html
Running 10s test @ http://127.0.0.1:8888/index.html
  4 threads and 20 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   557.60us    1.69ms  49.67ms   98.13%
    Req/Sec    12.09k     4.20k   24.55k    76.25%
  481385 requests in 10.03s, 28.46MB read
Requests/sec:  48016.14
Transfer/sec:      2.84MB

複数の作業者(フォークまたはステアリングの受信)で同じ番号。

これをあなたの環境で再現したいと思います!

全てのコメント14件

両方のマシンで正確なベンチマーク設定を共有できますか?

2019年からデフォルトのMacBookを入手し、Homebrewのpython3に対してデフォルト設定でHomebrewのwrkを実行しました。 パフォーマンスは大まかにジャプロントのカテゴリーにありました。

次に、Clear Linuxでpython3とコンパイル済みのwrk(非常にうまく機能することがわかっています)をデフォルト設定で実行しました。パフォーマンスは8分の1(10k対84k)でした。

通常はその逆で、LinuxはネットワーキングにおいてmacOSよりも優れているはずです

Linuxマシンが他のモジュールと一緒にそのpython3.8で125kを実行することを知っているので、10kはかなり離れています

ありがとう! 提供していた正確なPythonアプリケーションとコマンドラインパラメーター、およびwrk構成を共有してください。

実行中のシェルによってulimitによって報告されたfdsの最大数も提供できますか

最も単純なhelloworldアプリと同じで、デフォルトのwrk http:// localhost :8080以外の構成はありません。追加のパラメーターは一切なく、デフォルトで最小限に抑えられています。

私は時々より大きなテストを実行するので100万fdsが好きですが、wrkはこれに10しか使用しません

うーん、いくつかのベンチマークを実行しただけです。2つのvCPUを備えた完全に最適化されていないLinuxサーバーは問題ないようです。

import bjoern

def app(env,sr):
    sr('200 ok', [('content-length','0')])
    return ''

bjoern.run(app, 'localhost', 8888, reuse_port=1)
$ venv/wrk/wrk -t12 -c400 -d10s http://127.0.0.1:8888/index.html
Running 10s test @ http://127.0.0.1:8888/index.html
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.76ms    5.45ms 139.52ms   84.60%
    Req/Sec     3.93k     1.08k   19.63k    80.95%
  470512 requests in 10.09s, 27.82MB read
Requests/sec:  46628.11
Transfer/sec:      2.76MB
$ venv/wrk/wrk -t4 -c20 -d10s http://127.0.0.1:8888/index.html
Running 10s test @ http://127.0.0.1:8888/index.html
  4 threads and 20 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   557.60us    1.69ms  49.67ms   98.13%
    Req/Sec    12.09k     4.20k   24.55k    76.25%
  481385 requests in 10.03s, 28.46MB read
Requests/sec:  48016.14
Transfer/sec:      2.84MB

複数の作業者(フォークまたはステアリングの受信)で同じ番号。

これをあなたの環境で再現したいと思います!

Clear Linuxは、特に開発のためにIntelによって使用されており、最も代表的なものではない可能性があると聞きました。

それは意味がありません。 Clear Linuxはパフォーマンスの問題であり、私の最初のコメントでは、他のサーバーソフトウェアで非常に高い数値が得られると述べました。

私が指摘している点と私が報告しているバグは、Bjoernは他のサーバーソフトウェアと比較してmacOSで非常に競争力のあるパフォーマンスを持っていますが、Linuxでは同じサーバーソフトウェアとBjoernの違いはBjoernにとって非常に不利です。

つまり、Bjoernが遅いとは報告していませんが、そうではありませんが、Linuxでは、何かがおかしいように、奇妙なことに競争力がありません。

Linuxで8分

それは意味がありません。 Clear Linuxはパフォーマンスの問題であり、私の最初のコメントでは、他のサーバーソフトウェアで非常に高い数値が得られると述べました。

残念ながら、これは多くの問題に加えて、Clear Linuxがエキゾチックなディストリビューションであることが原因である可能性があります。さらに、Jonasは他のディストリビューションで調査結果を再現できませんでした。 Jonasが以前のコメントで要求した、最小限の再現可能な例を彼に提供できれば助かります。

たとえば、 https://hub.docker.com/_/clearlinuxを使用して、セットアップをコンテナーに複製してみることができます。

Jonasは実際にそれを複製したと思います。 2つのCPUの場合は48k-数値は、それらのCPUが正確に何であるかについての情報がなければ意味がありませんが、かなり低いように聞こえます。

いいえ、再現できず、例を探しています。

さて、違いはデフォルトのwrk設定で最も大きいです:

./wrk http://localhost:3000
Running 10s test @ http://localhost:3000
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.33ms   13.38ms  42.21ms   78.97%
    Req/Sec     6.02k     1.68k    9.64k    70.00%
  120611 requests in 10.07s, 10.81MB read
Requests/sec:  11982.66
Transfer/sec:      1.07MB

使用したような400の接続では、番号が異なります。

./wrk -c400 http://localhost:3000
Running 10s test @ http://localhost:3000
  2 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    13.05ms   14.71ms  45.77ms   78.16%
    Req/Sec    29.59k     4.64k   40.56k    70.00%
  588631 requests in 10.02s, 52.80MB read
Requests/sec:  58760.47
Transfer/sec:      5.27MB

しかし、どちらにしても、Linux上で同様の目標を持つ他のPythonサーバーに近づくことはありません。 ここでは、デフォルトのwrk設定で実行しています。

./wrk http://localhost:3000
Running 10s test @ http://localhost:3000
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    67.36us   41.30us   4.23ms   90.27%
    Req/Sec    74.29k     8.69k   98.37k    65.35%
  1493810 requests in 10.10s, 102.57MB read
Requests/sec: 147908.51
Transfer/sec:     10.16MB

差分が10倍を超える場合、400接続で2.5倍になります。 したがって、私が主に報告しているのは、デフォルトのwrk設定を実行する場合です。これは、差分が不当に大きい場合です。

これが非常に基本的なテスト例です。

import bjoern

# This simple test does not include routing
def application(env, start_response):
    start_response('200 OK', [])
    return b"Hello Python!"

# I get poor performance on Linux, much better on macOS?
# 10k ish on Linux, 84k on macOS, let's compare on macOS to make it even!
bjoern.run(application, "localhost", 3000)

これらの番号はすべて、同じPythonバージョンの10年以上前のラップトップで実行されています。

ありがとう、今すぐClear LinuxDockerコンテナで試してみてください。 セットアップのパフォーマンスを、Docker内で実行されているClear Linux、およびDocker内で実行されているUbuntuと比較してください。

また、最後の例のPythonサーバーと正確なアプリケーションコードを共有できますか?

これは私が持っているプロトタイプにすぎませんが、macOSでのJaprontoとBjoern、LinuxでのJaprontoを検討すると、同様の違いが見られます。 Clear Linuxは必要ありません。カーネル固有のものはなく、Dockerは実際のClear Linuxカーネルを提供することすらなく、独自のカーネルを提供します。 これはすべてのカーネルに適用されます。

いずれにせよ、私は実際には長い議論を探していませんでした。ベンチマークを行っているときに最初の調査結果を報告するだけでした。

リンゴとオレンジの比較です。 JaprontoはWSGIサーバーではありません。 とにかく好奇心のためだけにベンチマークします:)

ところで、パッケージのダウンロードには永遠に時間がかかり、パッケージ化されたlibevがないため、ClearLinuxのセットアップに取り掛かることはありませんでした。 だから、それは私の好意のためにあまりにも多くの時間を要しました。

このチケットは締め切らせていただきますが、お気軽にご相談ください!

このページは役に立ちましたか?
0 / 5 - 0 評価

関連する問題

alexted picture alexted  ·  12コメント

thedrow picture thedrow  ·  22コメント

jonashaag picture jonashaag  ·  18コメント

voroninman picture voroninman  ·  5コメント

ryanisnan picture ryanisnan  ·  11コメント