🥇अनुरोधों के बैच प्रोसेसिंग की समस्याएं और उनके समाधान (भाग 1)

लगभग सभी आधुनिक सॉफ़्टवेयर उत्पादों में कई सेवाएँ शामिल होती हैं। अक्सर, इंटरसर्विस चैनलों का लंबा प्रतिक्रिया समय प्रदर्शन समस्याओं का एक स्रोत बन जाता है। इस तरह की समस्या का मानक समाधान एकाधिक इंटरसर्विस अनुरोधों को एक पैकेज में पैक करना है, जिसे बैचिंग कहा जाता है।

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

प्रदर्शन परियोजना

स्पष्टता के लिए, आइए उस एप्लिकेशन की सेवाओं में से एक का उदाहरण देखें जिस पर मैं वर्तमान में काम कर रहा हूं।

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

तो, उनमें से प्रत्येक में प्रतिभागियों के पूर्वनिर्धारित सेट के साथ चैट रूम (दस्तावेजों के अनुरूप) हैं। नियमित चैट की तरह, संदेशों में टेक्स्ट और फ़ाइलें होती हैं और इन्हें उत्तर या अग्रेषित किया जा सकता है:

data class ChatMessage( // nullable так как появляется только после persist val id: Long? = null, /** Ссылка на автора */ val author: UserReference, /** Сообщение */ val message: String, /** Ссылки на аттачи */ // из-за особенностей связки JPA+СУБД проще поддерживать и null, и пустые списки val files: List<FileReference>? = null, /** Если является ответом, то здесь будет оригинал */ val replyTo: ChatMessage? = null, /** Если является пересылкой, то здесь будет оригинал */ val forwardFrom: ChatMessage? = null )

फ़ाइल और उपयोगकर्ता लिंक अन्य डोमेन के लिंक हैं। यहाँ हम इस तरह रहते हैं:

typealias FileReference = Long typealias UserReference = Long
उपयोगकर्ता डेटा को Keycloak में संग्रहीत किया जाता है और REST के माध्यम से पुनर्प्राप्त किया जाता है। यही बात फाइलों के लिए भी लागू होती है: फ़ाइलें और उनके बारे में जानकारी एक अलग फ़ाइल भंडारण सेवा में रहती है।

इन सेवाओं के लिए सभी कॉल हैं भारी अनुरोध. इसका मतलब यह है कि इन अनुरोधों को परिवहन करने का ओवरहेड किसी तृतीय-पक्ष सेवा द्वारा संसाधित होने में लगने वाले समय से कहीं अधिक है। हमारी परीक्षण बेंचों पर, ऐसी सेवाओं के लिए सामान्य कॉल समय 100 एमएस है, इसलिए हम भविष्य में इन नंबरों का उपयोग करेंगे।

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

/** В таком виде отдаются ссылки на сущности для фронта */ data class ReferenceUI( /** Идентификатор для url */ val ref: String, /** Видимое пользователю название ссылки */ val name: String ) data class ChatMessageUI( val id: Long, /** Ссылка на автора */ val author: ReferenceUI, /** Сообщение */ val message: String, /** Ссылки на аттачи */ val files: List<ReferenceUI>, /** Если являтся ответом, то здесь будет оригинал */ val replyTo: ChatMessageUI? = null, /** Если являтся пересылкой, то здесь будет оригинал */ val forwardFrom: ChatMessageUI? = null )

हमें निम्नलिखित को लागू करने की आवश्यकता है:

interface ChatRestApi { fun getLast(n: Int): List<ChatMessageUI> }

यूआई पोस्टफ़िक्स का अर्थ है फ्रंटएंड के लिए डीटीओ मॉडल, यानी, हमें आरईएसटी के माध्यम से क्या सेवा देनी चाहिए।

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

दार्शनिक विषयांतरChatMessageUI क्लास और ChatRestApi.getLast विधि दोनों सूची डेटा प्रकार का उपयोग करते हैं जब वास्तव में यह एक ऑर्डर किया गया सेट होता है। यह जेडीके में खराब है, इसलिए इंटरफ़ेस स्तर पर तत्वों के क्रम को घोषित करना (जोड़ने और हटाने के दौरान ऑर्डर को संरक्षित करना) काम नहीं करेगा। इसलिए उन मामलों में सूची का उपयोग करना आम बात हो गई है जहां एक ऑर्डर किए गए सेट की आवश्यकता होती है (एक LinkedHashSet भी है, लेकिन यह एक इंटरफ़ेस नहीं है)।
महत्वपूर्ण सीमा: हम मान लेंगे कि उत्तरों या स्थानांतरणों की कोई लंबी श्रृंखला नहीं है। यानी वे मौजूद हैं, लेकिन उनकी लंबाई तीन संदेशों से अधिक नहीं है। संदेशों की पूरी श्रृंखला को फ्रंटएंड पर प्रेषित किया जाना चाहिए।

बाहरी सेवाओं से डेटा प्राप्त करने के लिए निम्नलिखित एपीआई हैं:

interface ChatMessageRepository { fun findLast(n: Int): List<ChatMessage> } data class FileHeadRemote( val id: FileReference, val name: String ) interface FileRemoteApi { fun getHeadById(id: FileReference): FileHeadRemote fun getHeadsByIds(id: Set<FileReference>): Set<FileHeadRemote> fun getHeadsByIds(id: List<FileReference>): List<FileHeadRemote> fun getHeadsByChat(): List<FileHeadRemote> } data class UserRemote( val id: UserReference, val name: String ) interface UserRemoteApi { fun getUserById(id: UserReference): UserRemote fun getUsersByIds(id: Set<UserReference>): Set<UserRemote> fun getUsersByIds(id: List<UserReference>): List<UserRemote> }

यह देखा जा सकता है कि बाहरी सेवाएँ शुरू में बैच प्रोसेसिंग प्रदान करती हैं, और दोनों संस्करणों में: सेट के माध्यम से (तत्वों के क्रम को संरक्षित किए बिना, अद्वितीय कुंजियों के साथ) और सूची के माध्यम से (डुप्लिकेट हो सकते हैं - ऑर्डर संरक्षित है)।

सरल कार्यान्वयन

अनुभवहीन कार्यान्वयन

हमारे REST नियंत्रक का पहला अनुभवहीन कार्यान्वयन ज्यादातर मामलों में कुछ इस तरह दिखेगा:

class ChatRestController( private val messageRepository: ChatMessageRepository, private val userRepository: UserRemoteApi, private val fileRepository: FileRemoteApi ) : ChatRestApi { override fun getLast(n: Int) = messageRepository.findLast(n) .map { it.toFrontModel() } private fun ChatMessage.toFrontModel(): ChatMessageUI = ChatMessageUI( id = id ?: throw IllegalStateException("$this must be persisted"), author = userRepository.getUserById(author).toFrontReference(), message = message, files = files?.let { files -> fileRepository.getHeadsByIds(files) .map { it.toFrontReference() } } ?: listOf(), forwardFrom = forwardFrom?.toFrontModel(), replyTo = replyTo?.toFrontModel() ) }
सब कुछ बहुत स्पष्ट है, और यह एक बड़ा प्लस है।

हम बैच प्रोसेसिंग का उपयोग करते हैं और बैचों में बाहरी सेवा से डेटा प्राप्त करते हैं। लेकिन हमारी उत्पादकता का क्या होता है?

प्रत्येक संदेश के लिए, लेखक फ़ील्ड पर डेटा प्राप्त करने के लिए UserRemoteApi पर एक कॉल की जाएगी और सभी संलग्न फ़ाइलों को प्राप्त करने के लिए FileRemoteApi पर एक कॉल की जाएगी। ऐसा लगता है जैसे बस यही है. मान लीजिए कि चैटमैसेज के लिए फॉरवर्डफ्रॉम और रिप्लाईटू फ़ील्ड इस तरह से प्राप्त किए जाते हैं कि इसके लिए अनावश्यक कॉल की आवश्यकता नहीं होती है। लेकिन उन्हें ChatMessageUI में बदलने से रिकर्सन हो जाएगा, यानी कॉल काउंटर काफी बढ़ सकते हैं। जैसा कि हमने पहले उल्लेख किया है, आइए मान लें कि हमारे पास बहुत अधिक नेस्टिंग नहीं है और श्रृंखला तीन संदेशों तक सीमित है।

परिणामस्वरूप, हमें प्रति संदेश बाहरी सेवाओं के लिए दो से छह कॉल और संदेशों के पूरे पैकेज के लिए एक जेपीए कॉल मिलेगी। कॉल की कुल संख्या 2*N+1 से 6*N+1 तक भिन्न-भिन्न होगी। वास्तविक इकाइयों में यह कितना है? मान लीजिए कि एक पेज को रेंडर करने में 20 संदेश लगते हैं। इन्हें प्राप्त करने में 4 सेकंड से 10 सेकंड तक का समय लगेगा। भयानक! मैं इसे 500 एमएस के भीतर रखना चाहूंगा। और चूंकि उन्होंने फ्रंटएंड में निर्बाध स्क्रॉलिंग बनाने का सपना देखा था, इसलिए इस एंडपॉइंट के लिए प्रदर्शन आवश्यकताओं को दोगुना किया जा सकता है।

पेशेवरों:

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

कम:

बहुत छोटे पैकेटों के कारण भयानक प्रदर्शन।

यह दृष्टिकोण अक्सर सरल सेवाओं या प्रोटोटाइप में देखा जा सकता है। यदि परिवर्तन करने की गति महत्वपूर्ण है, तो सिस्टम को जटिल बनाना शायद ही इसके लायक है। साथ ही, हमारी बहुत ही सरल सेवा के लिए प्रदर्शन भयानक है, इसलिए इस दृष्टिकोण की प्रयोज्यता का दायरा बहुत संकीर्ण है।

अनुभवहीन समानांतर प्रसंस्करण

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

समानांतर प्रसंस्करण लागू करना बहुत सरल है:

override fun getLast(n: Int) = messageRepository.findLast(n).parallelStream() .map { it.toFrontModel() } .collect(toList())

समानांतर संदेश प्रसंस्करण का उपयोग करते हुए, हमें आदर्श रूप से 300-700 एमएस मिलते हैं, जो एक सरल कार्यान्वयन की तुलना में बहुत बेहतर है, लेकिन फिर भी पर्याप्त तेज़ नहीं है।

इस दृष्टिकोण के साथ, userRepository और fileRepository के अनुरोधों को समकालिक रूप से निष्पादित किया जाएगा, जो बहुत कुशल नहीं है। इसे ठीक करने के लिए आपको कॉल लॉजिक में काफी बदलाव करना होगा। उदाहरण के लिए, कंप्लीशनस्टेज (उर्फ कंप्लीटेबलफ्यूचर) के माध्यम से:

private fun ChatMessage.toFrontModel(): ChatMessageUI = CompletableFuture.supplyAsync { userRepository.getUserById(author).toFrontReference() }.thenCombine( files?.let { CompletableFuture.supplyAsync { fileRepository.getHeadsByIds(files).map { it.toFrontReference() } } } ?: CompletableFuture.completedFuture(listOf()) ) { author, files -> ChatMessageUI( id = id ?: throw IllegalStateException("$this must be persisted"), author = author, message = message, files = files, forwardFrom = forwardFrom?.toFrontModel(), replyTo = replyTo?.toFrontModel() ) }.get()!!

यह देखा जा सकता है कि प्रारंभ में सरल मैपिंग कोड कम समझ में आने लगा है। ऐसा इसलिए है क्योंकि हमें कॉल को बाहरी सेवाओं से अलग करना था जहां परिणामों का उपयोग किया जाता है। ये अपने आप में बुरा नहीं है. लेकिन कॉलों का संयोजन बहुत सुंदर नहीं दिखता है और एक विशिष्ट प्रतिक्रियाशील "नूडल" जैसा दिखता है।

यदि आप कोरआउटिन का उपयोग करते हैं, तो सब कुछ अधिक सभ्य दिखाई देगा:

private fun ChatMessage.toFrontModel(): ChatMessageUI = join( { userRepository.getUserById(author).toFrontReference() }, { files?.let { fileRepository.getHeadsByIds(files) .map { it.toFrontReference() } } ?: listOf() } ).let { (author, files) -> ChatMessageUI( id = id ?: throw IllegalStateException("$this must be persisted"), author = author, message = message, files = files, forwardFrom = forwardFrom?.toFrontModel(), replyTo = replyTo?.toFrontModel() ) }

कहाँ:

fun <A, B> join(a: () -> A, b: () -> B) = runBlocking(IO) { awaitAll(async { a() }, async { b() }) }.let { it[0] as A to it[1] as B }

सैद्धांतिक रूप से, इस तरह के समानांतर प्रसंस्करण का उपयोग करके, हमें 200-400 एमएस मिलेगा, जो पहले से ही हमारी अपेक्षाओं के करीब है।

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

ऐसी सेवा का उपयोग करते समय मेरा परिणाम 1300 संदेशों को संसाधित करने के लिए 1700-20 एमएस है। यह पहले कार्यान्वयन की तुलना में तेज़ है, लेकिन फिर भी समस्या का समाधान नहीं करता है।

समानांतर प्रश्नों का वैकल्पिक उपयोगयदि तृतीय-पक्ष सेवाएँ बैच प्रोसेसिंग प्रदान नहीं करती हैं तो क्या होगा? उदाहरण के लिए, आप इंटरफ़ेस विधियों के अंदर बैच प्रोसेसिंग कार्यान्वयन की कमी को छिपा सकते हैं:

interface UserRemoteApi { fun getUserById(id: UserReference): UserRemote fun getUsersByIds(id: Set<UserReference>): Set<UserRemote> = id.parallelStream() .map { getUserById(it) }.collect(toSet()) fun getUsersByIds(id: List<UserReference>): List<UserRemote> = id.parallelStream() .map { getUserById(it) }.collect(toList()) }

यदि आप भविष्य के संस्करणों में बैच प्रोसेसिंग देखने की आशा करते हैं तो यह समझ में आता है।
पेशेवरों:

संदेश-आधारित समानांतर प्रसंस्करण को आसानी से कार्यान्वित करें।
अच्छी मापनीयता.

विपक्ष:

विभिन्न सेवाओं के अनुरोधों को समानांतर में संसाधित करते समय डेटा अधिग्रहण को उसके प्रसंस्करण से अलग करने की आवश्यकता।
तृतीय-पक्ष सेवाओं पर बढ़ा हुआ भार।

यह देखा जा सकता है कि प्रयोज्यता का दायरा लगभग अनुभवहीन दृष्टिकोण के समान ही है। यदि आप दूसरों के बेरहम शोषण के कारण अपनी सेवा के प्रदर्शन को कई गुना बढ़ाना चाहते हैं तो समानांतर अनुरोध पद्धति का उपयोग करना समझ में आता है। हमारे उदाहरण में, प्रदर्शन 2,5 गुना बढ़ गया, लेकिन यह स्पष्ट रूप से पर्याप्त नहीं है।

कैशिंग

आप बाहरी सेवाओं के लिए जेपीए की भावना से कैशिंग कर सकते हैं, यानी प्राप्त वस्तुओं को एक सत्र के भीतर संग्रहीत कर सकते हैं ताकि उन्हें दोबारा प्राप्त न करें (बैच प्रोसेसिंग के दौरान सहित)। आप ऐसे कैश स्वयं बना सकते हैं, आप स्प्रिंग का उपयोग इसके @Cacheable के साथ कर सकते हैं, साथ ही आप हमेशा EhCache जैसे तैयार कैश का मैन्युअल रूप से उपयोग कर सकते हैं।

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

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

पेशेवरों:

कोड बदले बिना कैशिंग लागू करें।
उत्पादकता कई गुना बढ़ गई (कुछ मामलों में)।

विपक्ष:

गलत तरीके से उपयोग करने पर प्रदर्शन में कमी की संभावना।
बड़ी मेमोरी ओवरहेड, विशेष रूप से लंबे कैश के साथ।
जटिल अमान्यकरण, त्रुटियाँ जिनमें रनटाइम में कठिन-से-पुनरुत्पादन समस्याएं पैदा होंगी।

बहुत बार, कैश का उपयोग केवल डिज़ाइन समस्याओं को शीघ्रता से ठीक करने के लिए किया जाता है। इसका मतलब यह नहीं है कि उनका उपयोग नहीं किया जाना चाहिए। हालाँकि, आपको हमेशा उनके साथ सावधानी से व्यवहार करना चाहिए और पहले परिणामी प्रदर्शन लाभ का मूल्यांकन करना चाहिए, और उसके बाद ही कोई निर्णय लेना चाहिए।

हमारे उदाहरण में, कैश लगभग 25% की प्रदर्शन वृद्धि प्रदान करेगा। वहीं, कैश के काफी नुकसान हैं, इसलिए मैं यहां उनका उपयोग नहीं करूंगा।

परिणाम

इसलिए, हमने एक ऐसी सेवा के सरल कार्यान्वयन पर ध्यान दिया जो बैच प्रोसेसिंग का उपयोग करती है, और इसे गति देने के कुछ सरल तरीके भी।

इन सभी तरीकों का मुख्य लाभ सरलता है, जिसके कई सुखद परिणाम मिलते हैं।

इन विधियों के साथ एक आम समस्या खराब प्रदर्शन है, मुख्य रूप से पैकेट के आकार के कारण। इसलिए, यदि ये समाधान आपके अनुरूप नहीं हैं, तो अधिक कट्टरपंथी तरीकों पर विचार करना उचित है।

ऐसी दो मुख्य दिशाएँ हैं जिनमें आप समाधान खोज सकते हैं:

डेटा के साथ अतुल्यकालिक कार्य (एक आदर्श बदलाव की आवश्यकता है, इसलिए इस आलेख में चर्चा नहीं की गई है);
समकालिक प्रसंस्करण को बनाए रखते हुए बैचों का विस्तार।

बैचों के बढ़ने से बाहरी कॉलों की संख्या बहुत कम हो जाएगी और साथ ही कोड समकालिक रहेगा। लेख का अगला भाग इसी विषय पर समर्पित होगा।

स्रोत: www.habr.com

बैच क्वेरी प्रोसेसिंग की समस्याएं और उनके समाधान (भाग 1)