<p>werkzeug.formparserは、バイナリのアップロードが大きいと非常に遅くなります</p>

同じ問題があります。isoファイル（200m）をアップロードすると、request.formの最初の呼び出しに7秒かかります。

さらなる最適化には2つのことが興味深いようです-cythonの実験と、よりスマートなMIMEメッセージ解析のためのコンテンツサイトヘッダーの解釈の実験

（サブメッセージの内容の長さがわかっている場合は、行をスキャンする必要はありません）

簡単に言うと、ファイルをリクエスト本文で直接ストリーミングする場合（つまり、 application/multipart-formdataがない場合）、フォームパーサーを完全にバイパスし、 request.streamからファイルを直接読み取ります。

jQuery-File-Uploadのチャンクアップロード方法を使用すると、マルチパートアップロードでアップロード速度が遅くなるという同じ問題があります。 小さなチャンク（〜10MB）を使用する場合、転送速度は0〜12MB / sの間でジャンプしますが、ネットワークとサーバーは50MB / sを超える速度に完全に対応しています。 速度低下は、実際のアップロードとほぼ同じ時間がかかるCPUバウンドマルチパート解析によって引き起こされます。 残念ながら、ストリーミングアップロードを使用してマルチパート解析をバイパスすることは、バックグラウンドでストリーミングを実行できないiOSデバイスをサポートする必要があるため、実際にはオプションではありません。

@sekrauseによって提供されるパッチはPython2.7では機能しません。

@carbn ：最後の行をcollect = bytearray()変更することで、 Python2.7でパッチを機能させることができました。 これは、既存のバイト配列をクリアする代わりに、新しいバイト配列を作成するだけです。

@cuibonobo ：それは私が最初に変更したことですが、それでも別のエラーがありました。 現時点では動作中のパッチを確認できませんが、IIRCの歩留まりをyield _cont, collectからyield _cont, str(collect) 。 これにより、コードをテストでき、パッチによってマルチパート処理速度が約30％向上しました。 それは素晴らしいスピードアップですが、パフォーマンスはまだかなり悪いです。

もう少し調査すると、 werkzeug.wsgi.make_line_iterはすでにボトルネックになりすぎて、 parse_lines()を実際に最適化できないことがわかります。 このPython3テストスクリプトを見てください。

import io
import time
from werkzeug.wsgi import make_line_iter

filename = 'test.bin' # Large binary file
lines = 0

# load a large binary file into memory
with open(filename, 'rb') as f:
    data = f.read()
    stream = io.BytesIO(data)
    filesize = len(data) / 2**20 # MB

start = time.perf_counter()
for _ in make_line_iter(stream):
    lines += 1
stop = time.perf_counter()
delta = stop - start

print('File size: %.2f MB' % filesize)
print('Time: %.1f seconds' % delta)
print('Read speed: %.2f MB/s' % (filesize / delta))
print('Number of lines yielded by make_line_iter: %d' % lines)

Python3.5を使用した923MBのビデオファイルの場合、ラップトップでの出力は次のようになります。

File size: 926.89 MB
Time: 20.6 seconds
Read speed: 44.97 MB/s
Number of lines yielded by make_line_iter: 7562905

したがって、上記の最適化を適用し、完全になるまでさらに最適化しても、 make_line_iterデータを十分に高速に提供できないという理由だけで、大規模なバイナリアップロードの場合は最大45 MB / sに制限されます。境界をチェックするループ内の923MBのデータに対して750万回の反復を実行します。

唯一の素晴らしい最適化は、 parse_lines()を他のものに完全に置き換えることだと思います。 考えられる解決策は、ストリームのかなり大きなチャンクをメモリに読み込んでから、string.find（）（またはPython 3ではbytes.find（））を使用して、境界がチャンク内にあるかどうかを確認することです。 Pythonでは、find（）はCで記述された高度に最適化された文字列検索アルゴリズムであるため、ある程度のパフォーマンスが得られるはずです。 境界が2つのチャンクの間にある可能性がある場合に注意する必要があります。

受信時にストリームをチャンクで解析することについて言及したいと思います。 @siddhantgoelは、このすばらしい小さなパーサーを作成してくれました。 それは私にとって素晴らしい働きをしています。 https://github.com/siddhantgoel/streaming-form-data

唯一の優れた最適化は、parse_lines（）を完全に置き換えることだと思います

このために+1。

中間の一時ファイルを使用せずに、おそらくバックプレッシャを使用して、ユーザーのアップロードをS3に直接ストリーミングするためのブリッジを作成していますが、 werkzeugとflask状況は苛立たしいものです。 2つのパイプ間でデータを直接移動することはできません。

@lambdaq私はそれが修正される必要がある問題であることに同意します。 これが重要な場合は、動作を変更するパッチを確認させていただきます。

@lambdaqリクエスト本文で直接データをストリーミングし、 application/octet-streamを使用する場合、フォームパーサーはまったく起動せず、 request.stream使用できることに注意してください（つまり、一時ファイルなどはありません）。 。

私たちが抱えていた唯一の問題は、werkzeugフォームパーサーが、リクエストの本文を実際に解析する必要があるかどうかを知る前に、許可された最大コンテンツ長に対してコンテンツ長を熱心に

これにより、通常のフォームデータに最大コンテンツ長を設定できなくなりますが、非常に大きなファイルのアップロードも可能になります。

チェック機能を少し

リクエスト本文でデータを直接ストリーミングし、application / octet-streamを使用する場合、フォームパーサーはまったく起動せず、request.streamを使用できることに注意してください（つまり、一時ファイルなどはありません）。

残念ながら違います。 これは、マルチパートを使用した通常のフォームのアップロードです。

動作を変更するパッチを確認できれば幸いです。

ジェネレーターのsend()を使用してwerkzeug.wsgi.make_line_iterまたはparse_lines()をハックしようとしたので、 _iter_basic_lines()に信号を送って、行ではなくチャンク全体を出力できます。 それほど簡単ではないことがわかりました。

基本的に、ウサギ全体は'itertools.chain' object has no attribute 'send'始まります....😂

C（またはCythonなど）で記述されたネイティブの高速化を使用して、このコードをどれだけ高速化できるのだろうか。 セミラージ（数100 MBですが、多くのGBほど大きくはありません）ファイルを、アプリの使用方法を変更せずに（つまり、バッファリングする代わりに直接ストリーミングする）、より効率的に処理することが重要だと思います-多くのアプリケーションでは、これはやり過ぎで絶対に必要というわけではありませんが（実際には、現在のやや遅いパフォーマンスでもおそらく問題ありません）、物事を速くすることは常に素晴らしいことです！

別の可能な解決策は、 multipart解析ジョブをnginxにオフロードすることです

https://www.nginx.com/resources/wiki/modules/upload/

@ThiefMaster

見る

https://github.com/hydrogen18/multipart-python

https://github.com/defnull/multipart

両方のレポは死んでいるように見えます。

それで、これに対する既知の解決策はありませんか？

回避策があります👆

uwsgiでは、組み込みのchunked_read()関数を使用し、ストリームが入ってくると自分で解析します。99％の確率で機能しますが、まだ追跡していないバグがあります。 すぐに使用できるストリーミングフォームパーサーについては、以前のコメントを参照してください。 python2の下では遅いので、私たちは自分でロールしました、そしてそれは速いです。 :)

上からの引用：

私はそれが修正される必要がある問題であることに同意します。 これが重要な場合は、動作を変更するパッチを確認させていただきます。

今はこれに取り組む時間が本当にありません。 これがあなたが時間を費やしているものであるならば、パッチを提供することを検討して

@sdizazzo

しかし、それは私がまだ追跡していないバグがあります

ストリーミングフォームデータについて話しているのですか？ もしそうなら、私はバグが何であるかを知りたいです。

私たちの問題は、フォーム処理が遅いために同時リクエスト処理が妨げられ、 nomadがプロセスがハングして強制終了したと見なしてしまうことでした。

私の修正は、 werkzeug/formparser.py:MutlipartParser.parse_lines() sleep(0)を追加することwerkzeug/formparser.py:MutlipartParser.parse_lines() ：

            for i, line in enumerate(iterator):
                if not line:
                    self.fail('unexpected end of stream')

                # give other greenlets a chance to run every 100 lines
                if i % 100 == 0:
                    time.sleep(0)

このパッチを適用する場合は、 unexpected end of stream検索してください。

受信時にストリームをチャンクで解析することについて言及したいと思います。 @siddhantgoelは、このすばらしい小さなパーサーを作成してくれました。 それは私にとって素晴らしい働きをしています。 https://github.com/siddhantgoel/streaming-form-data

出向。
これにより、Flaskアプリへのファイルのアップロードが10倍以上高速化されます

@siddhantgoel
ストリーミングフォームデータを修正していただき、ありがとうございます。 私はついにギガバイトサイズのファイルを高速でメモリをいっぱいにすることなくアップロードできるようになりました！

パーサーをsans-ioに書き換えることについて説明している＃1788を参照してください。 ここでのフィードバックに基づいて、私はそれがこの問題にも対処すると思います。