🥊 🚝 ♈️ अमेज़न SQS परीक्षण 👨🏻‍🎨 ⬅️ 🤤

नेटवर्क में पहले से ही अमेज़ॅन के इस समाधान के प्रदर्शन की कई समीक्षाएं हैं, इस लेख में मैंने पहले से प्राप्त परिणामों की जांच करने के लक्ष्य का पीछा नहीं किया, मुझे कुछ विशेषताओं में दिलचस्पी थी जिन्हें अन्य स्रोतों में नहीं माना जाता है, अर्थात्:

प्रलेखन का कहना है कि अमेज़ॅन संदेश आदेश को रखने की कोशिश कर रहा है, यह कितनी अच्छी तरह से रखा गया है?
लॉन्ग पोलिंग का उपयोग करते समय संदेश कितनी तेजी से प्राप्त हो रहा है?
बैच प्रोसेसिंग स्पीड कितनी बढ़ जाती है?

समस्या का बयान

एरांग पर एडब्ल्यूएस के लिए सबसे समर्थित पुस्तकालय एर्क्लाउड है [1], लाइब्रेरी को इनिशियलाइज़ करने के लिए, बस स्टार्ट को कॉल करें और तरीकों को कॉन्फ़िगर करें, जैसा कि गितुब पर संकेत दिया गया है। मेरे संदेशों में निम्नलिखित फ़ंक्शन द्वारा उत्पन्न एक यादृच्छिक वर्ण सेट होगा:

random_string(0) -> []; random_string(Length) -> [random_char() | random_string(Length-1)]. random_char() -> random:uniform(95) + 31 .

गति माप के लिए, हम जाने-माने फ़ंक्शन का उपयोग करेंगे जो टाइमर का उपयोग करता है: tc, लेकिन कुछ परिवर्तनों के साथ:

 test_avg(M, F, A, R, N) when N > 0 -> {Ret, L} = test_loop(M, F, A, R, N, []), Length = length(L), Min = lists:min(L), Max = lists:max(L), Med = lists:nth(round((Length / 2)), lists:sort(L)), Avg = round(lists:foldl(fun(X, Sum) -> X + Sum end, 0, L) / Length), io:format("Range: ~b - ~b mics~n" "Median: ~b mics~n" "Average: ~b mics~n", [Min, Max, Med, Avg]), Ret. test_loop(_M, _F, _A, R, 0, List) -> {R, List}; test_loop(M, F, A, R, N, List) -> {T, Result} = timer:tc(M, F, [R|A]), test_loop(M, F, A, Result, N - 1, [T|List]).

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

 send_random(N, Queue) -> erlcloud_sqs:send_message(Queue, [N + 1 | random_string(6000 + random:uniform(6000))]), N + 1 .

और सांख्यिकी संग्रह के साथ उसकी पुकार:

 test_avg(?MODULE, send_random, [QueueName], 31, 20)

यहाँ 31 पहले संदेश की संख्या है, इस संख्या को संयोग से नहीं चुना गया है, तथ्य यह है कि erlang संख्याओं और तारों के अनुक्रमों के बीच अंतर नहीं करता है और संदेश में यह वर्ण संख्या 31 होगी, कम संख्याओं को SQS में प्रेषित किया जा सकता है, लेकिन इस मामले में निरंतर रेंज प्राप्त की जाती हैं छोटा (# x9 | #xA | #xD | [# x20 to # xD7FF] | [# xE000 to #xFFFD] | [# x10000 to # x10FFFF], अधिक जानकारी [2] और वैध सीमा से बाहर जाने पर आपको एक अपवाद मिलेगा। इस प्रकार, send_random फ़ंक्शन जनरेट करता है और कतार के नाम के साथ कतार में एक संदेश भेजता है, जिसकी शुरुआत में एक संख्या होती है जो इसकी संख्या निर्धारित करती है, फ़ंक्शन अगले नंबर की संख्या को वापस करता है, जिसे अगले फ़ंक्शन फ़ंक्शन द्वारा आगे उपयोग किया जाता है। Test_avg फ़ंक्शन क्वेनेम लेता है, जो send_random फ़ंक्शन का दूसरा तर्क बन जाता है, पहला तर्क संख्या और दोहराव की संख्या है।

फ़ंक्शन जो संदेश प्राप्त करेगा और उनके आदेश की जांच करेगा वह इस तरह दिखाई देगा:

 checkorder(N, []) -> N; checkorder(N, [H | T]) -> [{body, [M | _]}|_] = H, K = if M > N -> M; true -> io:format("Wrong ~b less than ~b~n", [M, N]), N end, checkorder(K, T). receive_checkorder(LastN, Queue) -> [{messages, List} | _] = erlcloud_sqs:receive_message(Queue), remove_list(Queue, List), checkorder(LastN, List).

संदेश हटाएं:

 remove_msg(_, []) -> wrong; remove_msg(Q, [{receipt_handle, Handle} | _]) -> erlcloud_sqs:delete_message(Q, Handle); remove_msg(Q, [_ | T]) -> remove_msg(Q, T). remove_list(_, []) -> ok; remove_list(Q, [H | T]) -> remove_msg(Q, H), remove_list(Q, T).

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

संदेश मिलाना

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

इस अंतर की गणना करने के लिए, यह केवल संदेश क्रम चेकिंग फ़ंक्शन को बदलने के लिए पर्याप्त है:

 checkorder(N, []) -> N; checkorder({N, Cnt, Sum, Max}, [H | T]) -> [{body, [M | _]}|_] = H, {N1, Cnt1, Sum1, Max1} = if M < N -> {N, Cnt + 1, Sum + N - M, if Max < N - M -> N - M; true -> Max end }; true -> {M, Cnt, Sum, Max} end, checkorder({N1, Cnt1, Sum1, Max1}, T).

श्रृंखला निष्पादन समारोह के लिए कॉल इस तरह दिखेगा:

 {_, Cnt, Sum, Max} = test_avg(?MODULE, receive_checkorder, [QueueName], {0, 0, 0, 0}, Size)

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

आकार (पीसी)	20	50	100	150	200	250	300	400	500	600	700	800	900	1000
अधिकतम ऑफसेट (पीसी)	11	32	66	93	65	139	184	155	251	241	218	249	359	227
औसत विस्थापन (पीसी)	5.3	10.5	23.9	43	25.6	45.9	48.4	65.6	74,2	74,2	78.3	72.3	110.8	82.8

पहली पंक्ति कतार में संदेशों की संख्या है, दूसरी अधिकतम ऑफसेट है, तीसरी औसत ऑफ़सेट है।

परिणामों ने मुझे आश्चर्यचकित किया, संदेश केवल मिश्रण नहीं करते हैं, इसमें बस कोई सीमा नहीं है, अर्थात, संदेशों की संख्या में वृद्धि के साथ, आपको देखी गई विंडो का आकार बढ़ाने की आवश्यकता है। ग्राफ रूप में भी यही:

लंबा मतदान

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

सत्यापन के लिए, हम दो प्रक्रियाएँ बनाएंगे, जिनमें से एक यादृच्छिक समय पर संदेश भेजेगा, और दूसरा हमेशा लंबे मतदान में होगा, जबकि संदेश भेजने और प्राप्त करने के क्षण बाद की तुलना के लिए सहेजे जाएंगे। इस मोड को सक्षम करने के लिए, कतार पैरामीटर में संदेश प्रतीक्षा समय = 20 सेकंड प्राप्त करें।

 send_sleep(L, Queue) -> timer:sleep(random:uniform(10000)), Call = erlang:now(), erlcloud_sqs:send_message(Queue, random_string(6000 + random:uniform(6000))), [Call | L].

यह फ़ंक्शन मिलीसेकंड की एक यादृच्छिक संख्या के लिए सो जाता है, जिसके बाद यह पल को याद करता है और एक संदेश भेजता है

 remember_moment(L, []) -> L; remember_moment(L, [_ | _]) -> [erlang:now() | L]. receive_polling(L, Queue) -> [{messages, List} | _] = erlcloud_sqs:receive_message(Queue), remove_list(Queue, List), remember_moment(L, List).

ये दो कार्य आपको संदेश प्राप्त करने और उन क्षणों को याद करने की अनुमति देते हैं जिन पर यह हुआ था। एक साथ इन कार्यों को स्पॉन के साथ निष्पादित करने के बाद, मुझे दो सूचियां मिलती हैं, जिसके बीच का अंतर संदेश को प्रतिक्रिया समय दिखाता है। यह इस तथ्य को ध्यान में नहीं रखता है कि संदेश मिश्रित हो सकते हैं, सामान्य तौर पर, यह बस प्रतिक्रिया समय को अतिरिक्त रूप से बढ़ाएगा।

आइए देखें क्या हुआ:

नींद का अंतराल	10000	7500	5000	2500
न्यूनतम समय (सेकंड)	0.27	0.28	0.27	0.66
अधिकतम समय (सेकंड)	10.25	7.8	5.36	5.53
औसत समय (सेकंड)	1.87	1.87	1.84	1.88

पहली पंक्ति भेजने की प्रक्रिया की अधिकतम देरी के रूप में निर्धारित मूल्य है। वह है: 10 सेकंड, 7.5 सेकंड ... बाकी लाइनें एक संदेश के लिए न्यूनतम, अधिकतम और औसत प्रतीक्षा समय हैं।

ग्राफ रूप में भी यही:

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

बैच भेज रहा है

सबसे पहले, आइए देखें कि संदेश भेजते समय कतार को "वार्म अप" करने का प्रभाव कितना महत्वपूर्ण है:

रिकॉर्ड की संख्या	20	50	100	150	200	250	300	400	500	600	700	800	900	1000
न्यूनतम समय (सेकंड)	0.1	0.1	0.1	0.09	0.09	0.09	0.09	0.1	0.09	0.1	0.1	0.09	0.09	0.09
अधिकतम समय (सेकंड)	0.19	0.37	0.41	0.41	0.37	0.38	0.37	0.43	0.39	0.66	0.74	0.48	0.53	0.77
औसत समय (सेकंड)	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12	0.12

एक ग्राफ के रूप में ही:

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

रिकॉर्ड की संख्या	20	50	100	150	200	250	300	400	500	600	700	800	900	1000
न्यूनतम समय (सेकंड)	0.001	0.14	0	0.135	0	0.135	0	0	0	0	0	0	0	0
अधिकतम समय (सेकंड)	0.72	0.47	0.65	0.65	0.69	0.51	0.75	0.75	0.76	0.73	0.82	0.79	0.74	0.91
औसत समय (सेकंड)	0.23	0.21	0.21	0.21	0.21	0.21	0.21	0.21	0.21	0.2	0.2	0.2	0.2	0.21

कोई संतृप्ति भी नहीं है, औसत लगभग 200ms है। कभी-कभी रीडिंग तुरन्त हुई (1 एमएस से अधिक तेज), लेकिन इसका मतलब है कि संदेश प्राप्त नहीं हुआ था, प्रलेखन के अनुसार, एसक्यूएस सर्वर ऐसा कर सकते हैं, आपको बस फिर से संदेश का अनुरोध करने की आवश्यकता है।

चलो सीधे ब्लॉक और बहु-थ्रेडेड परीक्षण पर जाएं।

दुर्भाग्य से, erlcloud लाइब्रेरी में संदेश भेजने वाले बैच के लिए फ़ंक्शंस नहीं हैं, लेकिन मौजूदा फ़ंक्शंस के आधार पर ऐसे फ़ंक्शंस को लागू करना मुश्किल नहीं है; संदेश भेजने वाले फ़ंक्शन में, आपको अनुरोध को निम्न में बदलने की आवश्यकता है:

 Doc = sqs_xml_request(Config, QueueName, "SendMessageBatch", encode_message_list(Messages, 1)),

और अनुरोध बनाने का कार्य जोड़ें:

 encode_message_list([], _) -> []; encode_message_list([H | T], N) -> MesssageId = string:concat("SendMessageBatchRequestEntry.", integer_to_list(N)), [{string:concat(MesssageId, ".Id"), integer_to_list(N)}, {string:concat(MesssageId, ".MessageBody"), H} | encode_message_list(T, N + 1)].

लाइब्रेरी को एपीआई के संस्करण को भी ठीक करना चाहिए, उदाहरण के लिए, 2011-10-01 पर, अन्यथा अमेज़ॅन आपके अनुरोधों के जवाब में एक बुरा अनुरोध वापस कर देगा।

परीक्षण कार्य अन्य परीक्षणों में उपयोग किए जाने वाले समान हैं:

 gen_messages(0) -> []; gen_messages(N) -> [random_string(5000 + random:uniform(1000)) | gen_messages(N - 1)]. send_batch(N, Queue) -> erlang:display(erlcloud_sqs:send_message_batch(Queue, gen_messages(10))), N + 1 .

यहां हमें केवल संदेशों की लंबाई बदलनी थी ताकि पूरा पैकेज 64kb में फिट हो जाए, अन्यथा एक अपवाद फेंक दिया जाता है।

रिकॉर्डिंग के लिए निम्न डेटा प्राप्त किया गया था:

धागों की संख्या	0	1	2	4	5	10	20	50	100
अधिकतम विलंब (सेकंड)	0.452	0761	0.858	1.464	1.698	3.14	5.272	11,793	20,215
औसत देरी (सेकंड)	0.118	0.48	0.436	0.652	0.784	1.524	3.178	9.1	19,889
संदेश समय (सेकंड)	0.118	0.048	0.022	0.017	0.016	0.016	0.017	0.019	0.02

यहाँ 0 का मतलब 1 स्ट्रीम में एक-एक करके पढ़ना है, फिर 1 को 10 से 1 स्ट्रीम में पढ़ना, 10 को 2 स्ट्रीम में, 10 को 4 स्ट्रीम और इतने पर

पढ़ने के लिए:

धागों की संख्या	0	1	2	4	5	10	20	50	100
अधिकतम विलंब (सेकंड)	0.762	2.998	2.511	2.4	2.606	2.751	4.944	11,653	18,517
औसत देरी (सेकंड)	0.205	1,256	1.528	1.566	1.532	1.87	3.377	7823	17,786
संदेश समय (सेकंड)	0.205	0.126	0.077	0.04	0.031	0.02	0.019	0.017	0.019

ग्राफ पढ़ने और लिखने के लिए बैंडविड्थ दिखा रहा है (प्रति सेकंड संदेश):

नीला लिख रहा है, लाल पढ़ रहा है।

इस डेटा से हम यह निष्कर्ष निकाल सकते हैं कि अधिकतम प्रवाह 10 धाराओं के क्षेत्र में लिखने के लिए प्राप्त किया जाता है, और पढ़ने के लिए - लगभग 50, धाराओं की संख्या में और वृद्धि के साथ, प्रति यूनिट समय भेजे गए संदेशों की संख्या में वृद्धि नहीं होती है।

निष्कर्ष

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

संदर्भ

एटलक्लाउड ऑन जीथब github.com/gleber/erlcloud
www.w3.org/TR/REC-xml/#charsets