S3 में मल्टीथ्रेडेड फ़ाइल अपलोड

यह लेख अमेजन S3 में मणि aws-sdk का उपयोग करते हुए रूबी में मल्टीथ्रेडिंग का उपयोग करके फ़ाइलों को अपलोड करने के वास्तविक उपयोग और प्रदर्शन लाभ को दिखाता है।

एक सरल से शुरू करते हैं

आधिकारिक (यानी, अमेज़ॅन द्वारा विकसित) रत्न aws-sdk का उपयोग करके एक फ़ाइल अपलोड को लागू करना काफी सरल है। यदि आप Amazon Web Services (AWS) प्राधिकरण मापदंडों को बनाने के प्रारंभिक भाग को छोड़ देते हैं, तो कोड में तीन लाइनें होती हैं:

def upload_to_s3(config, src, dst) #     S3,      config s3 = AWS::S3.new( :access_key_id => config['access_key_id'], :secret_access_key => onfig['secret_access_key']) #  ,    'dst'  S3 (   ) s3_file = s3.buckets[config['bucket_name']].objects[dst] #    src    (   ) s3_file.write(:file => src, :acl => :public_read) end 

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

भागों में एक फ़ाइल डाउनलोड करें

Aws-sdk में भागों में एक फ़ाइल डाउनलोड करने के लिए, एक multipart_upload विधि है। आइए देखें इसकी खासियत:

 def multipart_upload_to_s3(src, dst, config) s3 = AWS::S3.new( :access_key_id => config['access_key_id'], :secret_access_key => onfig['secret_access_key']) s3_file = s3.buckets[config['bucket_name']].objects[dst] #   src    src_io = File.open(src, 'rb') #    read_size = 0 uploaded_size = 0 parts = 0 #    src_size = File.size(src) #    s3_file = s3_file.multipart_upload({:acl => :public_read}) do |upload| while read_size < src_size #          buff = src_io.readpartial(config['part_size']) #   read_size += buff.size part_number = parts += 1 # ,     S3 upload.add_part :data => buff, :part_number => part_number end end #    src_io.close s3_file end 

यह एक साधारण डाउनलोड की तुलना में अधिक जटिल लगता है। हालाँकि, नई विधि के महत्वपूर्ण लाभ हैं:

• भागों बेतरतीब ढंग से डाउनलोड किया जा सकता है
• दूसरे के डाउनलोड को शुरू करने के लिए एक भाग के डाउनलोड के पूरा होने की प्रतीक्षा करने की आवश्यकता नहीं है

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

भागों में गुणा फ़ाइल डाउनलोड

इस समस्या को हल करने के लिए कई दृष्टिकोण हैं:

• थ्रेड्स की निश्चित संख्या: फ़ाइल को एन भागों में विभाजित किया गया है (थ्रेड्स एन की संख्या से), प्रत्येक भाग समानांतर में डाउनलोड किया गया है;
• निश्चित भाग का आकार: फ़ाइल एस मान से अधिक नहीं के आकार के भागों में विभाजित है, प्रत्येक भाग समानांतर में अपलोड किया गया है;
• मिश्रित: फ़ाइल को एस मान से अधिक नहीं के आकार के भागों में विभाजित किया गया है, प्राप्त भागों को समानांतर में डाउनलोड किया जाता है, लेकिन एक समय में एन थ्रेड्स से अधिक नहीं।

व्यावहारिक दृष्टिकोण से, यह मिश्रित दृष्टिकोण है जो सबसे सुविधाजनक है, क्योंकि:

• API S3 में एक भाग के न्यूनतम आकार (5Mb) की सीमा होती है;
• बड़ी संख्या में थ्रेड का उपयोग दक्षता को कम करता है।

यहाँ मल्टीथ्रेड फ़ाइल अपलोड के लिए कोड है:

 def threaded_upload_to_s3(src, dst, config) s3 = AWS::S3.new( :access_key_id => config['access_key_id'], :secret_access_key => onfig['secret_access_key']) s3_file = s3.buckets[config['bucket_name']].objects[dst] src_io = File.open(src, 'rb') read_size = 0 uploaded_size = 0 parts = 0 src_size = File.size(src) s3_file = s3_file.multipart_upload({:acl => :public_read}) do |upload| #        upload_threads = [] #   ( ),   “” mutex = Mutex.new max_threads = [config['threads_count'], (src_size.to_f / config['part_size']).ceil].min #       max_threads.times do |thread_number| upload_threads << (Thread.new do #     while true #    ,         #   mutex.lock #  ,        break unless read_size < src_size #          buff = src_io.readpartial(config['part_size']) #   read_size += buff.size part_number = parts += 1 #   mutex.unlock # ,     S3 upload.add_part :data => buff, :part_number => part_number end end) end #      upload_threads.each{|thread| thread.join} end src_io.close s3_file end 

धागे बनाने के लिए, हम मानक थ्रेड क्लास का उपयोग करते हैं (रूबी में मल्टीथ्रेडिंग के साथ काम करने की मूल बातें आलेख habrahabr.ru/post/94574 में वर्णित हैं)। आपसी अपवादों को लागू करने के लिए, हम मानक म्यूटेक्स वर्ग द्वारा कार्यान्वित सरलतम बाइनरी सेमाफोर (म्यूटेक्स) का उपयोग करते हैं।

सेमाफोर की आवश्यकता क्यों है? उनकी मदद से, हम कोड के एक खंड को चिह्नित करते हैं (जिसे महत्वपूर्ण कहा जाता है) जो केवल एक समय में एक धागे को निष्पादित कर सकता है। शेष थ्रेड्स को तब तक इंतजार करना होगा जब तक कि सेमाफोर पर थ्रेड महत्वपूर्ण खंड को छोड़ नहीं देता। आमतौर पर, अर्ध-संसाधनों का उपयोग साझा संसाधनों तक उचित पहुंच प्रदान करने के लिए किया जाता है। इस मामले में, सामान्य संसाधन हैं: इनपुट ऑब्जेक्ट src_io और चर read_size और भागों। बफ़र और part_number चर थ्रेड के भीतर स्थानीय घोषित किए जाते हैं (यानी, थ्रेड.न्यू डू ... एंड ब्लॉक) और इसलिए साझा नहीं किए जाते हैं।

आप लेख www.tutorialspoint.com/ruby/ruby_multithreading.htm में रूबी में सेमाफोर और मल्टीथ्रेडिंग के बारे में अधिक पढ़ सकते हैं

तुलना परिणाम

हम कई परीक्षण फ़ाइलों (1 एमबी, 10 एमबी, 50 एमबी, 150 एमबी आकार में) पर विभिन्न तरीकों का उपयोग करके डाउनलोड गति को मापते हैं और इसे तालिका में सारांशित करते हैं:

	फ़ाइल	भागों	धाराओं	अपलोड, एमबी / एस	multipart_upload, Mb / s	पिरोया_अपलोड, एमबी / एस
1	64k	1	1	0.78	0.29 (37%)	0.29 (37%)
2	512K	1	1	2.88	1.84 (64%)	1.65 (57%)
3	1 एमबी	1	1	3.39	2.38 (70%)	2.58 (76%)
4	10 एमबी	2	2	5.06	4.50 (89%)	7.69 (152%)
5	50 एमबी	10	5	4.48	4.41 (98%)	9.02 (201%)
6	50 एमबी	10	10	4.33	4.44 (103%)	8.49 (196%)
7	150MB	30	5	4.34	4.43 (102%)	9.22 (212%)
8	150MB	30	10	4.48	4.52 (101%)	8.90 (199%)

उसी क्षेत्र में यूरोपीय संघ पश्चिम (आयरलैंड) क्षेत्र में एस 3 स्टोरेज के लिए एक मशीन से फ़ाइलों को डाउनलोड करके परीक्षण किया गया था। प्रत्येक फ़ाइल के लिए 10 अनुक्रमिक परीक्षणों की एक श्रृंखला का प्रदर्शन किया गया था।
यदि हम 4-8 परीक्षण के लिए एक सरल विधि द्वारा इंजेक्शन दर का मूल्यांकन करते हैं, तो माप त्रुटि लगभग 8% है, जो काफी स्वीकार्य है।
छोटी फ़ाइलों पर भागों (मल्टीपार्ट_पुलोड) में डाउनलोड करना सरल और बड़ी फ़ाइलों की तुलना में सबसे खराब परिणाम दिखा।
मल्टीथ्रेडेड डाउनलोड (थ्रेडेड_उपलोड) ने एक भाग से फाइलों पर उसी तरह की दक्षता दिखाई जैसे कि भागों में डाउनलोड (जो काफी स्पष्ट है)। लेकिन बड़ी फ़ाइलों पर, हमारे पास एक महत्वपूर्ण लाभ है - दो बार तक (सामान्य डाउनलोड की तुलना में)।
भाग के इष्टतम आकार और धाराओं की संख्या का पता लगाने के लिए कोई कार्य नहीं थे, लेकिन बड़ी फ़ाइलों पर 5 से 10 तक की धाराओं को बढ़ाने से महत्वपूर्ण प्रभाव नहीं हुआ।

निष्कर्ष

मल्टीप्रेडेड फ़ाइल अपलोडिंग उन फाइलों पर सामान्य से अधिक प्रभावी साबित हुई, जिनमें एक से अधिक भाग शामिल हैं, गति में वृद्धि - दो गुना तक।
वैसे, यह एक ऐसी विधि बनाने के लिए सुविधाजनक होगा जो फ़ाइल आकार के आधार पर सबसे उपयुक्त डाउनलोड विधि चुनती है।
उदाहरणों में स्रोत कोड Github: github.com/whisk/s3up पर पोस्ट किया गया है