<p>werkzeug.formparser वास्तव में बड़े बाइनरी अपलोड के साथ धीमा है</p>

को निर्मित 3 मार्च 2016 · 25टिप्पणियाँ · स्रोत: pallets/werkzeug

जब मैं फ्लास्क में किसी भी बड़ी बाइनरी फ़ाइल का multipart/form-data अपलोड करता हूं, तो वे अपलोड बहुत आसानी से सीपीयू बाउंड होते हैं (पायथन के साथ 100% सीपीयू की खपत) I / O के बजाय किसी भी तेजी से नेटवर्क कनेक्शन पर बाध्य होते हैं।

CPU प्रोफाइलिंग का थोड़ा सा पता चलता है कि इन अपलोड के दौरान लगभग सभी CPU समय werkzeug.formparser.MultiPartParser.parse_parts() में खर्च होता है। इसका कारण यह है कि विधि parse_lines() पैदावार _a lot_ of very small chunks, कभी-कभी तो सिर्फ बाइट्स :

# we have something in the buffer from the last iteration.
# this is usually a newline delimiter.
if buf:
    yield _cont, buf
    buf = b''

तो parse_parts() बहुत से छोटे पुनरावृत्तियों (100 एमबी की फ़ाइल के लिए 2 मिलियन से अधिक) के माध्यम से एकल "लाइनों" को संसाधित करता है, हमेशा आउटपुट स्ट्रीम में केवल बहुत ही छोटा हिस्सा या एकल बाइट्स लिखता है। यह उन सारी प्रक्रिया को धीमा कर देता है और बहुत तेजी से सीपीयू को बाध्य करता है।

एक त्वरित परीक्षण से पता चलता है कि पहले bytearray parse_lines() डेटा एकत्र करके और उस डेटा को parse_parts() self.buffer_size केवल पैदावार करने से पहले एक स्पीड-अप बहुत आसानी से संभव है।

buf = b''
collect = bytearray()
for line in iterator:
    if not line:
        self.fail('unexpected end of stream')

    if line[:2] == b'--':
        terminator = line.rstrip()
        if terminator in (next_part, last_part):
            # yield remaining collected data
            if collect:
                yield _cont, collect
            break

    if transfer_encoding is not None:
        if transfer_encoding == 'base64':
            transfer_encoding = 'base64_codec'
        try:
            line = codecs.decode(line, transfer_encoding)
        except Exception:
            self.fail('could not decode transfer encoded chunk')

    # we have something in the buffer from the last iteration.
    # this is usually a newline delimiter.
    if buf:
        collect += buf
        buf = b''

    # If the line ends with windows CRLF we write everything except
    # the last two bytes.  In all other cases however we write
    # everything except the last byte.  If it was a newline, that's
    # fine, otherwise it does not matter because we will write it
    # the next iteration.  this ensures we do not write the
    # final newline into the stream.  That way we do not have to
    # truncate the stream.  However we do have to make sure that
    # if something else than a newline is in there we write it
    # out.
    if line[-2:] == b'\r\n':
        buf = b'\r\n'
        cutoff = -2
    else:
        buf = line[-1:]
        cutoff = -1

    collect += line[:cutoff]

    if len(collect) >= self.buffer_size:
        yield _cont, collect
        collect.clear()

यह परिवर्तन मेरी 34 एमबी परीक्षण फ़ाइल के लिए अपलोड समय को 4200 एमएस से घटाकर मेरी मशीन पर लोकलहोस्ट पर लगभग 1100 एमएस तक कर देता है, जो प्रदर्शन में लगभग 4 गुना वृद्धि है। सभी परीक्षण विंडोज (64-बिट पायथन 3.4) पर किए जाते हैं, मुझे यकीन नहीं है कि यह लिनक्स पर बहुत अधिक समस्या है।

यह अभी भी ज्यादातर सीपीयू बाध्य है, इसलिए मुझे यकीन है कि अनुकूलन के लिए और भी अधिक संभावनाएं हैं। मुझे लगता है कि जब मुझे थोड़ा और समय मिलेगा, तो मैं इसे देखूंगा।

bug

स्रोत

sekrause

👍6

सबसे उपयोगी टिप्पणी

जैसा कि यह प्राप्त होता है मैं विखंडू में धारा पर पार्स करने का उल्लेख करना चाहता था। @siddhantgoel ने हमारे लिए इस महान छोटे पार्सर को लिखा है। यह मेरे लिए बहुत अच्छा काम कर रहा है। https://github.com/siddhantgoel/streaming-form-data

sdizazzo 2 जून 2017

👍5

सभी 25 टिप्पणियाँ

मेरे पास भी यही समस्या है, जब मैं एक आईएसओ फ़ाइल (200 मीटर) अपलोड करता हूं, तो पहली कॉल रिक्वेस्ट.फॉर्म में 7s लगेंगे

languanghao 18 मार्च 2016

आगे अनुकूलन के लिए 2 चीजें दिलचस्प लगती हैं - साइथन के साथ प्रयोग करना, और होशियार माइम संदेश पार्सिंग के लिए सामग्री-साइट हेडर की व्याख्या के साथ प्रयोग करना

(यदि आपको उप-संदेश की सामग्री-लंबाई पता है तो लाइनों के लिए स्कैन करने की आवश्यकता नहीं है)

RonnyPfannschmidt 18 मार्च 2016

बस एक त्वरित नोट, कि यदि आप फ़ाइल को सीधे अनुरोध निकाय में स्ट्रीम करते हैं (अर्थात application/multipart-formdata ), तो आप फॉर्म पार्सर को पूरी तरह से बायपास कर देते हैं और फ़ाइल को सीधे request.stream से पढ़ते हैं।

lnielsen 22 अग॰ 2016

मैं jQuery-File- अपलोड की chunked अपलोड विधि का उपयोग करते समय मल्टीपार्ट अपलोड के साथ धीमी अपलोड गति के साथ एक ही मुद्दा है। छोटे विखंडू (~ 10 एमबी) का उपयोग करते समय, स्थानांतरण गति 0 और 12 एमबी / एस के बीच कूद जाती है, जबकि नेटवर्क और सर्वर 50 एमबी / एस से अधिक गति के लिए पूरी तरह से सक्षम होते हैं। मंदी सीपीयू बाउंड मल्टीपार्ट पार्सिंग के कारण होती है जो वास्तविक अपलोड के समान ही समय लेती है। अफसोस की बात है, मल्टीपार्ट पार्सिंग को बायपास करने के लिए स्ट्रीमिंग अपलोड का उपयोग करना वास्तव में एक विकल्प नहीं है क्योंकि मुझे iOS उपकरणों का समर्थन करना चाहिए जो पृष्ठभूमि में स्ट्रीमिंग नहीं कर सकते हैं।

@Sekrause द्वारा प्रदान किया गया पैच अच्छा लग रहा है लेकिन अजगर 2.7 में काम नहीं करता है।

carbn 18 अक्तू॰ 2016

@carbn : मैं अंतिम पंक्ति को collect = bytearray() बदलकर पायथन 2.7 में काम करने में सक्षम था। यह सिर्फ मौजूदा को साफ करने के बजाय एक नया ब्योरा बनाता है।

cuibonobo 18 अक्तू॰ 2016

@ क्यूइबोनोबो : यह पहली चीज है जिसे मैंने बदला लेकिन फिर भी एक और त्रुटि थी। मैं इस समय काम करने वाले पैच की जाँच नहीं कर सकता, लेकिन IIRC की पैदावार को yield _cont, collect से yield _cont, str(collect) बदलना पड़ा। इसने कोड को जांचने की अनुमति दी और पैच ने मल्टीपार्ट प्रसंस्करण प्रक्रिया में लगभग 30% वृद्धि प्राप्त की। यह एक अच्छा स्पीडअप है, लेकिन प्रदर्शन अभी भी बहुत बुरा है।

carbn 18 अक्तू॰ 2016

थोड़ी और जांच से पता चलता है कि werkzeug.wsgi.make_line_iter पहले से ही बहुत अधिक अड़चन है वास्तव में parse_lines() का अनुकूलन करने में सक्षम होने के लिए। इस पायथन 3 टेस्ट स्क्रिप्ट को देखें:

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)

पायथन 3.5 के साथ 923 एमबी वीडियो फ़ाइल के लिए आउटपुट मेरे लैपटॉप पर कुछ इस तरह दिखता है:

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

इसलिए, भले ही आप मेरे अनुकूलन को ऊपर लागू करते हैं और इसे तब तक आगे बढ़ाते हैं, जब तक कि पूर्णता तक आप अभी भी ~ 45 एमबी / एस तक ही सीमित रहेंगे बाइनरी अपलोड के लिए केवल इसलिए कि make_line_iter आपको डेटा को तेजी से पर्याप्त नहीं दे सकता है और आप ' सीमा के लिए जाँच करने वाले आपके लूप में 923 एमबी डेटा के लिए 7.5 मिलियन पुनरावृत्तियों को किया जाएगा।

मुझे लगता है कि एकमात्र महान अनुकूलन कुछ और के साथ parse_lines() को पूरी तरह से बदल देगा। एक संभावित समाधान जो दिमाग में आता है, वह है स्ट्रीम की एक बड़ी बड़ी चंक को मेमोरी में पढ़ना फिर स्ट्रिंग (समय) (या बाइट्स) (पाइथन 3 में बाइट्स) का उपयोग करना ताकि यह जांचा जा सके कि सीमा कबाड़ में है। पायथन में () सी में लिखा गया एक उच्च अनुकूलित स्ट्रिंग खोज एल्गोरिथ्म है, जिससे आपको कुछ प्रदर्शन करना चाहिए। आपको बस उस मामले का ध्यान रखना होगा जहां सीमा दो टुकड़ों के बीच सही हो सकती है।

sekrause 18 अक्तू॰ 2016

sdizazzo 2 जून 2017

👍5

मुझे लगता है कि एकमात्र महान अनुकूलन पूरी तरह से parse_lines को बदलने के लिए होगा ()

इसके लिए +1।

मैं किसी भी मध्यवर्ती अस्थायी फ़ाइलों के बिना उपयोगकर्ता के अपलोड को सीधे S3 में स्ट्रीम करने के लिए एक पुल लिख रहा हूं, संभवतः बैकपेक्चर के साथ, और मुझे werkzeug और flask निराशा मिल रही है। आप दो पाइपों के बीच डेटा को सीधे स्थानांतरित नहीं कर सकते।

lambdaq 20 जून 2017

@ लेम्बडाक मैं मानता हूं कि यह एक समस्या है जिसे ठीक करने की आवश्यकता है। यदि यह आपके लिए महत्वपूर्ण है, तो मुझे व्यवहार को बदलते हुए पैच की समीक्षा करके खुशी होगी।

davidism 20 जून 2017

@lambdaq ध्यान दें कि यदि आप केवल अनुरोध बॉडी में सीधे डेटा स्ट्रीम करते हैं और application/octet-stream तो फॉर्म पार्सर बिल्कुल भी किक नहीं करता है और आप request.stream उपयोग कर सकते हैं (अर्थात कोई अस्थायी फ़ाइलें आदि) ।

एकमात्र समस्या जो हमारे पास थी वेर्केज फॉर्म फॉर्म पार्सर उत्सुकता से अनुमति दे रहा है कि क्या यह वास्तव में अनुरोध निकाय को पार्स करना चाहिए, यह जानने से पहले सामग्री की अधिकतम लंबाई के खिलाफ लंबाई की जांच कर रहा है ।

यह आपको सामान्य फ़ॉर्म डेटा पर अधिकतम सामग्री लंबाई सेट करने से रोकता है, लेकिन बहुत बड़ी फ़ाइल अपलोड की भी अनुमति देता है।

हमने इसे फ़ंक्शन को थोड़ा सा पुन: व्यवस्थित करके इसे ठीक किया। निश्चित नहीं है कि यह इस अपस्ट्रीम को प्रदान करने के लिए समझ में आता है क्योंकि कुछ एप्लिकेशन मौजूदा व्यवहार पर भरोसा कर सकते हैं।

lnielsen 20 जून 2017

ध्यान दें कि यदि आप केवल अनुरोध बॉडी में सीधे डेटा स्ट्रीम करते हैं और एप्लिकेशन / ऑक्टेट-स्ट्रीम का उपयोग करते हैं तो फॉर्म पार्सर बिल्कुल भी किक नहीं करता है और आप रिक्वेस्ट का उपयोग कर सकते हैं।

दुर्भाग्य से नहीं। यह मल्टीपार्ट के साथ सिर्फ सामान्य फॉर्म अपलोड है।

मुझे व्यवहार को बदलते हुए एक पैच की समीक्षा करने में खुशी होगी।

मैंने जनरेटर के send() का उपयोग करके werkzeug.wsgi.make_line_iter या parse_lines() हैक करने की कोशिश की, इसलिए हम लाइनों के बजाय पूरे विखंडू का उत्सर्जन करने के लिए _iter_basic_lines() का संकेत दे सकते हैं। यह इतना आसान नहीं निकला।

असल में, खरगोश पूरे 'itertools.chain' object has no attribute 'send' .... 😂 से शुरू होता है

lambdaq 21 जून 2017

मुझे आश्चर्य है कि C (या साइथन आदि) में लिखे गए देशी स्पीडअप का उपयोग करके इस कोड को कितना खर्च किया जा सकता है। मुझे लगता है कि अर्ध-बड़ी (कुछ 100 एमबी, लेकिन कई जीबी में बड़ी नहीं) फाइलों को अधिक कुशलता से संभालना महत्वपूर्ण है बिना यह बदले कि एप्लिकेशन उनका उपयोग कैसे करता है (यानी बफरिंग के बजाय सीधे उन्हें स्ट्रीमिंग) - कई अनुप्रयोगों के लिए यह महत्वपूर्ण होगा ओवरकिल और बिल्कुल आवश्यक नहीं है (वास्तव में, यहां तक कि वर्तमान कुछ धीमी गति से प्रदर्शन शायद उनके लिए ठीक है) लेकिन चीजें तेजी से बनाना हमेशा अच्छा होता है!

ThiefMaster 21 जून 2017

एक अन्य संभावित समाधान multipart nginx को पार्स करने का काम है

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

lambdaq 30 सित॰ 2017

@ThiefMaster

ले देख

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

https://github.com/defnull/multipart

lambdaq 14 दिस॰ 2017

दोनों रेपो मृत दिखते हैं।

ThiefMaster 14 दिस॰ 2017

तो क्या इसका कोई ज्ञात समाधान नहीं है?

mdemin914 1 फ़र॰ 2018

वहाँ एक समाधान है 👆

lnielsen 1 फ़र॰ 2018

Uwsgi के तहत, हम इसका उपयोग chunked_read() फ़ंक्शन में करते हैं और इसमें आते ही स्ट्रीम को पार्स कर देते हैं। यह 99% समय काम करता है, लेकिन इसमें एक बग है जिसे मुझे अभी तक ट्रैक करना है। आउट-ऑफ-द-बॉक्स स्ट्रीमिंग फॉर्म पार्सर के लिए मेरी पिछली टिप्पणी देखें। Python2 के तहत यह धीमा था, इसलिए हमने अपना रोल किया और यह तेज है। :)

sdizazzo 2 फ़र॰ 2018

ऊपर से उद्धरण:

मैं मानता हूं कि यह एक समस्या है जिसे ठीक करने की जरूरत है। यदि यह आपके लिए महत्वपूर्ण है, तो मुझे व्यवहार को बदलते हुए पैच की समीक्षा करके खुशी होगी।

मेरे पास अभी इस समय काम करने का समय नहीं है। यदि यह कुछ ऐसा है जिस पर आप समय बिता रहे हैं, तो कृपया एक पैच योगदान

davidism 2 फ़र॰ 2018

@sdizazzo

लेकिन यह एक बग है कि मैं अभी तक नीचे ट्रैक करने के लिए है

क्या आप स्ट्रीमिंग-फ़ॉर्म-डेटा के बारे में बात कर रहे हैं? यदि हां, तो मुझे यह जानना अच्छा लगेगा कि बग क्या है।

siddhantgoel 3 फ़र॰ 2018

हमारी समस्या यह थी कि धीमी गति के प्रसंस्करण ने समवर्ती अनुरोध से निपटने को रोका जिससे nomad को लगता है कि इस प्रक्रिया को लटका दिया गया और इसे मार दिया गया।

मेरा फिक्स 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 खोज करें।

kneufeld 21 जुल॰ 2018

जैसा कि यह प्राप्त होता है मैं विखंडू में धारा पर पार्स करने का उल्लेख करना चाहता था। @siddhantgoel ने हमारे लिए इस महान छोटे पार्सर को लिखा है। यह मेरे लिए बहुत अच्छा काम कर रहा है। https://github.com/siddhantgoel/streaming-form-data

दूसरा है।
यह 10 से अधिक कारक द्वारा मेरे फ्लास्क ऐप पर फ़ाइल अपलोड को गति देता है

patrislav1 12 अक्तू॰ 2018

🎉1

@ सिद्दांतगेल
स्ट्रीमिंग-फॉर्म-डेटा के साथ आपके फिक्स के लिए बहुत बहुत धन्यवाद। मैं अंत में अच्छी गति पर गीगाबाइट आकार की फाइलें अपलोड कर सकता हूं और बिना मेमोरी भरे!

ghost 10 सित॰ 2019

🎉1

# 1788 देखें जो संस को फिर से लिखने के लिए चर्चा करता है। यहां प्रतिक्रिया के आधार पर, मुझे लगता है कि इस मुद्दे को भी संबोधित करेंगे।

davidism 12 अप्रैल 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

<p>werkzeug.formparser वास्तव में बड़े बाइनरी अपलोड के साथ धीमा है</p>

सबसे उपयोगी टिप्पणी

सभी 25 टिप्पणियाँ

संबंधित मुद्दों