यह सब एक सरल कार्य के साथ शुरू हुआ: 100 मेगाबाइट नेटवर्क पर rsync का उपयोग करके बड़ी मात्रा में डेटा डाउनलोड करें। यह सवाल उठा कि क्या इस प्रक्रिया को तेज किया जा सकता है। शीर्ष उपयोगिता ने दिखाया कि एन्क्रिप्शन स्रोत सर्वर पर 10 प्रतिशत से अधिक प्रोसेसर नहीं लेता है, इसलिए यह निर्णय लिया गया कि डेटा संपीड़न की कोशिश की जा सकती है। तब यह मेरे लिए स्पष्ट नहीं था कि क्या प्रोसेसर के पास आवश्यक गति से डेटा पैक करने के लिए पर्याप्त प्रदर्शन होगा, इसलिए सबसे छोटा संपीड़न अनुपात सेट किया गया था, अर्थात्, rsync लिए ध्वज --compress-level=1 rsync । यह पता चला कि प्रोसेसर लोड 65% से अधिक नहीं था, अर्थात, प्रोसेसर का प्रदर्शन पर्याप्त था, जबकि डेटा डाउनलोड की गति थोड़ी बढ़ गई थी।

उसके बाद, सामान्य संपीड़न कार्यक्रमों की प्रयोज्यता का विश्लेषण करने पर सवाल उठा
एक नेटवर्क पर डेटा स्थानांतरित करने के लिए।

स्रोत डेटा संग्रह

पहला काम विश्लेषण के लिए प्रारंभिक डेटा एकत्र करना था। चुनाव * निक्स दुनिया में व्यापक संपीड़न कार्यक्रमों पर गिर गया। सभी प्रोग्राम मानक Ubuntu 11.10 रिपॉजिटरी से स्थापित किए गए थे:

  प्रोग्राम संस्करण टेस्ट कुंजी डिफ़ॉल्ट
 lzop 1.03 1, 3, 7-9 3
 gzip 1.3.12 1-9 6
 bzip2 1.0.5 1-9 9
 xz 5.0.0 0-9 7 

आधिकारिक साइट: lzop , gzip , bzip2 , xz ।

bzip2 BWT एल्गोरिथ्म पर आधारित है, बाकी LZ77 एल्गोरिथ्म और इसके संशोधनों पर आधारित हैं।

लोज़ॉप के लिए, 2-6 के संपीड़न अनुपात समान हैं, और इसलिए परीक्षण नहीं किया गया है।

परीक्षण प्रणाली एक इंटेल P8600 लैपटॉप (कोर 2 डुओ, 2.4 गीगाहर्ट्ज) था
c 4 जीबी रैम उबंटू 11.10 64-बिट के तहत चल रहा है।

परीक्षण के लिए, कई अलग-अलग डेटा सेट का उपयोग किया गया था:

• बड़े सी ++ प्रोजेक्ट के ओपन कोड ओपनऑफैम डॉट कॉम का स्रोत कोड टार में पैक किया गया है। इसमें सोर्स कोड, पीडीएफ डॉक्यूमेंटेशन और कुछ बुरी तरह से कंप्रेस्ड साइंटिफिक डेटा होते हैं।
  
  असम्पीडित क्षमता: 127641600 बाइट्स = 122 MiB
  
• बड़े paraview.org प्रोजेक्ट का बाइनरी वितरण, टार में पैक किया गया। इसमें मुख्य रूप से .so पुस्तकालय फाइलें शामिल हैं।
  
  असम्पीडित क्षमता: 392028160 बाइट्स = 374 MiB
  
• बाइनरी वैज्ञानिक डेटा का एक सेट।
  
  असम्पीडित आकार: 151367680 बाइट्स = 145 MiB
  

ठीक है, और अधिक "क्लासिक" सेट:

• लिनक्स कर्नेल हेडर टार में पैक।
  
  असम्पीडित क्षमता: 56657920 बाइट्स = 55 MiB
  
• टैक में पैक gcc संकलक के लिए स्रोत कोड।
  
  असम्पीडित क्षमता: 490035200 बाइट्स = 468 MiB
  

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

परिणामों पर डिस्क I / O के प्रभाव को बाहर करने के लिए, सभी फाइलों को /run/shm में रखा गया था (यह लिनक्स में साझा की गई मेमोरी है, जिसे फ़ाइल सिस्टम के साथ संचालित किया जा सकता है)।

प्रत्येक माप 3 बार किया गया था। नतीजतन, तीन का न्यूनतम समय उपयोग किया गया था।

माप के परिणाम

परिणाम पैकिंग समय के निर्देशांक में रेखांकन में दिखाए जाते हैं - पैक्ड फ़ाइल का आकार।

अंजीर। 1: gcc संकलक स्रोतों के लिए परिणामों का ग्राफ:



अंजीर। 2: पैरा व्यू के द्विआधारी वितरण के लिए परिणामों का ग्राफ:



अंजीर। 3: द्विआधारी वैज्ञानिक डेटा के एक सेट के लिए परिणामों का ग्राफ:



इसके लिए रेखांकन: कर्नेल हेडर और ओपनफोम सोर्स कोड ।

टिप्पणियों:

1. 7-9 की संपीड़न दरों पर lzop फ़ाइल के आकार में बड़ी कमी के बिना बहुत धीमा हो जाता है, और gzip की तुलना में बहुत कम खो देता है। ये lzop सम्पीडन दर पूरी तरह से बेकार हैं।
   
   डिफ़ॉल्ट संपीड़न अनुपात के साथ, lzop अपेक्षा के अनुरूप है, बहुत तेज है। -1 का कम्प्रेशन रेशियो ज्यादा समय नहीं देता है, जिससे फाइल का आकार बड़ा हो जाता है।
   
2. gzip अपेक्षा के अनुसार व्यवहार करता है। संपीड़न अनुपात बदलते समय ग्राफ का "सही" रूप।
   
3. bzip2 बहुत प्रतिस्पर्धी नहीं था। ज्यादातर मामलों में, यह कम संपीड़न अनुपात xz को संपीड़न और गति के मामले में खो देता है। अपवाद कर्नेल हेडर हैं और gcc स्रोत कोड (अर्थात विशुद्ध रूप से पाठ्य सूचना) जिस पर वे प्रतिस्पर्धा करते हैं। इस प्रकाश में, यह अजीब है कि bzip2 इंटरनेट पर xz की तुलना में अधिक लोकप्रिय है। यह शायद इस तथ्य के कारण है कि दूसरा काफी युवा है और अभी तक "मानक" बनने में कामयाब नहीं हुआ है।
   
   यह भी ध्यान देने योग्य है कि विभिन्न कुंजी संपीड़न अनुपात को बदलते हैं और bzip2 रनटाइम बहुत ही महत्वहीन है।
   
4. उच्च पैरामीटर मूल्यों पर xz एक उच्च संपीड़न अनुपात प्रदर्शित करता है, लेकिन यह बहुत धीरे-धीरे काम करता है और बहुत बड़ी मात्रा में मेमोरी को संपीड़ित करने की आवश्यकता होती है (लगभग 690 एमबी -9 पर, आवश्यक स्मृति आकार मान में इंगित किया गया है)। अनपैकिंग के लिए मेमोरी का आकार बहुत छोटा है, लेकिन यह अभी भी बन सकता है
   कुछ अनुप्रयोगों के लिए सीमा।
   
   लघु संपीड़न अनुपात रनटाइम में gzip -9 के करीब आते हैं, एक बेहतर संपीड़न अनुपात प्रदान करते हैं।
   
   सामान्य तौर पर, आप देख सकते हैं कि xz संपीड़न अनुपात और समय के अनुपात का एक काफी बड़ा चयन देता है।
   
5. LZ-77 पर आधारित कार्यक्रमों की अनपैकिंग जल्दी से होती है, और कम्प्रेशन अनुपात (उसी प्रोग्राम के भीतर) में वृद्धि के साथ, अनपैकिंग का समय थोड़ा कम हो जाता है।
   
   Bzip2 के साथ, विघटन धीमा है, और संपीड़न अनुपात बढ़ने के साथ विघटन समय बढ़ता है।

विश्लेषण: परिदृश्य 1 - अनुक्रमिक संचालन

किसी नेटवर्क पर डेटा ट्रांसमिशन के इस परिदृश्य पर विचार करें: पहले, डेटा पैक किया जाता है, फिर नेटवर्क पर प्रसारित होता है, फिर अनपैक किया जाता है। फिर कुल समय होगा:

  t = t_c + s / bw + t_d

जहाँ t_c पैकिंग समय है, s बाइट्स में पैक्ड फ़ाइल का आकार है, bw बाइट्स / s में नेटवर्क बैंडविड्थ है, t_d समय है।

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

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

हम जिस चीज की तलाश कर रहे हैं वह एक उत्तल पतवार ( eng। उत्तल पतवार) से ज्यादा कुछ नहीं है। कई बिंदुओं के उत्तल पतवार के निर्माण के लिए कई एल्गोरिदम विकसित किए गए हैं। मैंने यहां से अजगर के कार्यान्वयन का उपयोग किया।

उत्तल पतवार के निर्माण के बाद, इससे संबंधित बिंदु हमारे इष्टतम एल्गोरिदम होंगे, और उन्हें जोड़ने वाले किनारों के ढलान सीमा बैंडविद होंगे।

इस प्रकार, हम अपनी फ़ाइलों के लिए ऐसे इष्टतम एल्गोरिदम प्राप्त करते हैं:

विश्लेषण: परिदृश्य 2 - स्ट्रीम संपीड़न

अब एक और परिदृश्य पर विचार करें: डेटा पैक किया गया है, और तुरंत पैक होने पर, इसे नेटवर्क पर भेजा जाता है, और प्राप्त होने पर इसे तुरंत अनपैक कर दिया जाता है।

फिर कुल डेटा ट्रांसफर का समय योग से नहीं, बल्कि नेटवर्क पर पैकेजिंग, अनपैकिंग और ट्रांसमिशन द्वारा निर्धारित किया जाता है।

चयनित नेटवर्क बैंडविड्थ के लिए निरंतर-समय वक्र तब एक सीधी रेखा पर एक शीर्ष के साथ एक कोण की तरह दिखेगा

  t = s / bw

और नीचे और ऊपर की बाईं ओर दो किरणें।

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

इस तरह के उपयोग के मामले के लिए परिणाम इस प्रकार हैं:

अंतिम टिप्पणियाँ

1. सब कुछ लिखा केवल बड़ी मात्रा में डेटा के हस्तांतरण के साथ परिदृश्यों पर लागू होता है, और अन्य परिदृश्यों पर लागू नहीं होता है, उदाहरण के लिए, कई छोटे संदेशों के हस्तांतरण के साथ।
   
2. यह अध्ययन एक मॉडल प्रकृति का था और वास्तविक जीवन में उत्पन्न होने वाली सभी विशेषताओं के लिए पूरी तरह से खाता नहीं है। यहाँ उनमें से कुछ हैं:
   
   
   • डिस्क I / O को ध्यान में नहीं रखा गया है।
   • कई प्रोसेसर कोर का उपयोग करने की उपस्थिति और संभावना पर ध्यान नहीं दिया जाता है।
   • यह ध्यान में नहीं रखा जाता है कि सर्वर अनुप्रयोग के दौरान, एक और प्रोसेसर लोड उसी समय मौजूद हो सकता है, जिससे कम से कम संसाधन संपीड़न के लिए निकल जाएं।
   
   
3. Google snappy इस अध्ययन में शामिल नहीं है। ऐसा कई कारणों से हुआ।
   
   
   • सबसे पहले, इसमें एक मूल कमांड लाइन उपयोगिता नहीं है (वास्तव में, एक तृतीय-पक्ष स्निपिप है , लेकिन मुझे नहीं लगता कि इसे कोई मानक माना जा सकता है)।
   • दूसरे, यह अन्य अनुप्रयोगों के लिए अभिप्रेत है।
   • तीसरा, यह lzop से भी तेज होने का वादा करता है, जिसका अर्थ है कि इसके संचालन के समय को सही ढंग से मापना बहुत मुश्किल हो सकता है।
   
   

व्यावहारिक उदाहरण

यह ज्ञात है कि कम दूरी पर बड़ी मात्रा में जानकारी देने के लिए सबसे तेज़ चैनलों में से एक हार्ड ड्राइव के साथ एक साइकिल कूरियर है।

गणना। की दूरी 10 किलोमीटर हो। साइकिल कूरियर एक घंटे और एक आधे (सामान्य गति से और सभी प्रकार की देरी, लोडिंग और अनलोडिंग को ध्यान में रखते हुए) में एक गोल-यात्रा उड़ान करेगा। इसे 8 घंटे के कार्य दिवस में 6 उड़ानें दें। उसे अपने साथ 1 टीबी के 10 डिस्क्स ले जाएं। फिर एक दिन में वह 60 टीबी का परिवहन करेगा। यह 60 टीबी / (24 * 3600) s = 662 MiB / s के थ्रूपुट के साथ एक राउंड-द-क्लॉक लाइन ऑपरेशन के बराबर है, जो लगभग 5 Gb / s है। बुरा नहीं है।

परिणाम बताते हैं कि यदि आप मेरे लैपटॉप के कोर के समान एक कोर पर ऐसी संचार लाइन के लिए डेटा को संपीड़ित करने का प्रयास करते हैं, तो संपीड़न की अनुपस्थिति इष्टतम है।

लेकिन अगर हम डेटा को एक USB 2.0 हार्ड ड्राइव में स्थानांतरित करने के मामले पर विचार करते हैं, तो यह लगभग 30 एमबी / एस की गति के साथ परिदृश्य 2 के समान है, अगर हम केवल ट्रांसफर पक्ष पर खर्च किए गए समय को ध्यान में रखते हैं।

हमारे चार्ट को देखते हुए, हम पाते हैं: lzop -3 हमारे परीक्षण डेटा सेट के लिए बाहरी USB हार्ड ड्राइव पर डेटा स्थानांतरित करने के लिए इष्टतम है।

यदि हम पहली बार संपीड़ित करते हैं और फिर इसे एक बाहरी ड्राइव पर कॉपी करते हैं, तो यह परिदृश्य 1 है, और फिर lzop -1 स्रोत कोड और बाइनरी वितरण के लिए खर्च किए गए कुल समय के संदर्भ में इष्टतम है, और खराब संकुचित बाइनरी डेटा के लिए - कोई संपीड़न नहीं।

संबंधित लिंक

1. इसी तरह की तुलना: http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gzip_vs_bzip2_vs_lzma_vs_lzma2-xz_benchmark_reloaded
2. एक और तुलना: http://www.linuxjournal.com/node/8051/