C ++ में प्रदर्शन में सुधार की पेचीदगियों पर, या यह नहीं करने के लिए कैसे

एक बार, कई साल पहले, एक ग्राहक मेरे पास आया, और एक अद्भुत परियोजना को समझने, और काम की गति बढ़ाने के निर्देशों के लिए आंसू बहाने लगा ।

संक्षेप में, कार्य यह था - सी ++ में एक निश्चित रोबोट है जो HTML पृष्ठों को स्ट्रिप्स करता है, और एक डेटाबेस (MySQL) में इकट्ठे तह होता है। बहुत अधिक कार्यक्षमता और LAMP पर वेब के साथ - लेकिन इसका कहानी से कोई लेना-देना नहीं है।

पिछली टीम ने क्लाउड में एक 4-कोर Xeon पर प्रबंधित किया था, जिसमें कलेक्टर और डेटाबेस दोनों के एक ही तरह के अलग-अलग सर्वर पर 100% CPU उपयोग के साथ 2 पेज प्रति सेकंड की शानदार संग्रह गति प्राप्त की गई थी।



वैसे, यह महसूस करते हुए कि वे ऐसा नहीं कर सकते, बैंगलोर से "मजबूत पेशेवरों की टीम" ने आत्मसमर्पण किया और बिखरे हुए हैं, इसलिए इसके अलावा स्रोतों का एक गुच्छा - "कुछ भी नहीं!" मोतियों के अलावा ”(सी)।

हम PHP में और डेटाबेस स्कीमा में चीजों को किसी अन्य समय में डालने की पेचीदगियों के बारे में बात करेंगे, मैं केवल उस कौशल का एक उदाहरण दूंगा जो हमारे पास आया है।

शव परीक्षा हो रही है

इस तरह के एक गंभीर डेटाबेस लोड ने मुझे पहली जगह में दिलचस्पी दी। मैं विस्तृत लॉगिंग चालू करता हूं - और सभी जगहों पर अपने आप पर बाल बाहर निकालना शुरू करता हूं, यहां यह है।

निश्चित रूप से, इंटरफ़ेस से कार्य डेटाबेस में बनाए गए थे, और रोबोट ने प्रति सेकंड 50 बार पूछताछ की - एक नया कार्य प्रकट नहीं हुआ? इसके अलावा, डेटा को स्वाभाविक रूप से इंटरफ़ेस के लिए सुविधाजनक तरीके से बाहर रखा गया है, और रोबोट के लिए नहीं। परिणाम अनुरोध में तीन आंतरिक शामिल हैं।

"एक बार प्रति सेकंड" द्वारा अंतराल को तुरंत बढ़ाएं। मैं पागल अनुरोध को हटाता हूं, वह है - तीन फ़ील्ड की एक नई प्लेट जोड़ें और वेब से तालिकाओं पर एक ट्रिगर लिखें ताकि यह स्वचालित रूप से भर जाए, और सरल में बदल जाए

select * from new_table where status = Pending 

नई तस्वीर - कलेक्टर अभी भी 100% व्यस्त है, डेटाबेस 2% व्यस्त है, अब प्रति सेकंड चार पृष्ठ हैं।

प्रोफाइलर को उठाओ

और अचानक यह पता चलता है कि 80% रनटाइम पर अद्भुत EnterCriticalSection और SkipCriticalSection विधियों का कब्जा है। और उन्हें एक प्रसिद्ध कंपनी के मानक आवंटनकर्ता से (अनुमानित रूप से) कहा जाता है।

शाम ख़त्म होना बंद हो जाती है, लेकिन मैं समझता हूं कि बहुत काम है और दिल से फिर से लिखना होगा।

और निश्चित रूप से, मेरे पूर्ववर्तियों ने नियमित रूप से भावों के एक समूह के साथ HTML बायडलॉर्स को पार्स करना पसंद किया, क्योंकि एसएएक्स बहुत जटिल है।

यह परिचित होने का समय है - और मुझे क्या सुधार हुआ है?

एक विचार किरण के साथ समय से पहले अनुकूलन के खतरे

यह देखकर कि डेटाबेस 100% भरा हुआ था, लोग दृढ़ता से आश्वस्त थे कि प्रसंस्करण के लिए सूची में नए URL सम्मिलित करना धीमा था।

मुझे यह भी समझना मुश्किल है कि इस विशेष कोड के अनुकूलन से उन्हें क्या निर्देशित किया गया। लेकिन दृष्टिकोण ही! सिद्धांत रूप में, यह यहाँ धीमा है, अभी धीमा है।

इसके लिए वे इस तरह के टोटके लेकर आए:

1. अतुल्यकालिक सम्मिलित अनुरोध कतार
2. स्मृति में एक विशाल हैशपॉट, स्व-लिखित, एक विशाल लॉक के साथ जो स्मृति में सभी पारित यूआरएल को याद करता है। और चूंकि यह एक सर्वर था, ऐसे अनुकूलन के बाद इसे नियमित रूप से पुनरारंभ करना आवश्यक था। उन्होंने अपने कैश की सफाई पूरी नहीं की।
3. उदाहरण के लिए बहुत सारे जादू की कमी, डेटाबेस से URL के अगले बैच को संसाधित करने के लिए, 400 से अधिक प्रविष्टियां नहीं ली गई हैं। 400 क्यों? और उठा लिया।
4. डेटाबेस में "लेखकों" की संख्या बड़ी थी, और प्रत्येक ने चक्र में अपना हिस्सा चमकाने की कोशिश की, वह अचानक भाग्यशाली था।

और निश्चित रूप से, कई अन्य मोती उपलब्ध थे।

सामान्य तौर पर, कोड के विकास को देखना बहुत ही शिक्षाप्रद था। आपने भंडारण के लाभ को अस्वीकार नहीं किया है - सब कुछ सावधानीपूर्वक टिप्पणी की गई है। इस तरह

 void GodClass::PlaceToDB(const Foo* bar, ...) { /*      1,  */ /*      2 -     ,  */ /*      3 -  ,      ,  */ .... /*    N-1,        ,  */ //   -   } 

मैंने क्या किया

बेशक, सभी चालें तुरंत फेंक दी गईं, मैं सिंक्रोनस सम्मिलन लौटा, और डुप्लिकेट को काटने के लिए डेटाबेस में बाधा डाली गई (विशालकाय लॉक और स्व-लिखित हैशमप के साथ नृत्य करने के बजाय)।

मैंने ऑटो-इंक्रीमेंट फ़ील्ड को भी हटा दिया, उनके बजाय एक यूयूआईडी डाला (एक नए मूल्य की गणना करने के लिए एक अंतर्निहित लॉक टेबल रेंगना सकता है)। उसी समय, मैंने गंभीरता से तालिका को कम कर दिया, और फिर प्रति पंक्ति 20K पर - यह आश्चर्य की बात नहीं है कि डेटाबेस डूब रहा है।

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

परिणाम 15 पृष्ठ प्रति सेकंड है।

हालांकि, री-प्रोफाइलिंग में सफलता में सुधार नहीं दिखा। बेशक, बेहतर वास्तुकला के कारण 7 गुना तेजी भी रोटी है, लेकिन पर्याप्त नहीं है। आखिरकार, वास्तव में, सभी मूल जाम बने रहे, मैंने केवल अनुकूलित टुकड़ों को मौत के लिए हटा दिया।

मेगाबाइट संरचित फ़ाइलों को पार्स करने के लिए नियमित अभिव्यक्ति खराब हैं

मैं अध्ययन करना जारी रखता हूं कि मेरे सामने क्या किया गया है, मैं अज्ञात लेखकों के दृष्टिकोण का आनंद लेता हूं।

मेरे--डाई-ka!

ट्रैक्टर की कृपा से, लोगों ने इस तरह से डेटा प्राप्त करने की समस्या को हल किया (प्रत्येक का अपना नियमित अभिव्यक्ति का सेट है)।

• HTML में सभी टिप्पणियों को काटें
• जावास्क्रिप्ट टिप्पणियाँ बाहर काट दिया
• कट स्क्रिप्ट टैग
• शैली टैग काटें
• उन्होंने सिर से दो अंक लिए
• शरीर को छोड़कर सब कुछ काट दो
• अब सभी "एक href" को एक साथ रखें और उन्हें काट लें
• शरीर में, सभी अनावश्यक डिव और टेबल को काट दिया गया, साथ ही चित्रों को भी
• फिर टेबल लेआउट को हटा दिया गया था
• बाकी हिस्सों में, पी, मजबूत, एम, आई, बी, जी, आदि टैग हटा दिए गए थे।
• और अंत में, शेष सादे पाठ में, हमें तीन और अंक मिले

इस दृष्टिकोण से आश्चर्यजनक रूप से, यह प्रति सेकंड कम से कम 2 पृष्ठ चबाता है।

यह स्पष्ट है कि मैं ट्यूनिंग के बाद खुद को भाव नहीं उद्धृत करता हूं - यह अपठनीय स्क्विगल्स की एक विशाल शीट है।

यह सब नहीं है - निश्चित रूप से, सही बूस्ट लाइब्रेरी का उपयोग किया गया था, और सभी ऑपरेशन std :: string ( सही तरीके से - लेकिन एचटीएमएल को और कहाँ पर रखा गया था? ) वैचारिक नहीं है! केवल कट्टर! )। यह वह जगह है जहाँ स्मृति आवंटन की पागल राशि आती है।

मैं SAX- शैली में एक चार * और एक साधारण HTML पार्सर लेता हूं, मुझे आवश्यक संख्याएं याद हैं, मैं समानांतर में URL निकालता हूं। दो दिन का काम, और निहारना।

परिणाम 200 पृष्ठों प्रति सेकंड है।

पहले से ही स्वीकार्य है, लेकिन पर्याप्त नहीं है। केवल 100 बार।

शेल के लिए एक और दृष्टिकोण

मैं एक नई रूपरेखा के परिणामों की ओर मुड़ता हूं। यह बेहतर हो गया, लेकिन अभी भी बहुत सारे आवंटन हैं, और किसी कारण से Boost to_lower () पहले स्थान पर बाहर हो गया।

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

मैं to_lower () के अत्यधिक उपयोग को हटाता हूं, मैं URL को फिर से लिखता हूं * st के बजाय redistributions के बिना * string: string। उसी समय मैं कुछ चक्रों का अनुकूलन कर रहा हूं।

परिणाम प्रति सेकंड 300 पृष्ठ है।

इस समाप्त होने पर, त्वरण 150 बार प्राप्त किया गया था, हालांकि त्वरण के लिए अभी भी भंडार थे। और इसलिए उसने 2 सप्ताह से अधिक की हत्या कर दी।

निष्कर्ष

हमेशा की तरह निष्कर्ष - शैली का एक क्लासिक। प्रदर्शन का मूल्यांकन करते समय उपकरणों का उपयोग करें, सिर से आविष्कार न करें। सूर्य को मैन्युअल रूप से सेट करने के बजाय व्यापक (या व्यापक) तैयार पुस्तकालयों का उपयोग करें।

और संत कनेक्टियस आपके साथ उच्च प्रदर्शन कर सकता है!