अनुरोधों और उनके समाधानों के बैच प्रसंस्करण की समस्याएं (भाग 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 एमएस है, इसलिए भविष्य में हम इन नंबरों का उपयोग करेंगे।

हमें सभी आवश्यक जानकारी के साथ अंतिम एन संदेशों को प्राप्त करने के लिए एक सरल 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 >
}

पोस्टफिक्स यूआई का मतलब है, फ्रंटएंड के लिए डीटीओ मॉडल, जो कि हमें REST के माध्यम से देना चाहिए।

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


एक महत्वपूर्ण सीमा: हम मानते हैं कि प्रतिक्रियाओं की कोई लंबी श्रृंखला या आगे नहीं है। यही है, वे हैं, लेकिन उनकी लंबाई तीन संदेशों से अधिक नहीं है। फ्रंट-एंड संदेश श्रृंखला को संपूर्णता में प्रेषित किया जाना चाहिए।

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

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 >
}

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

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

Naive कार्यान्वयन

हमारे 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 पर एक कॉल किया जाएगा। लगता तो सब है। मान लें कि ChatMessage के लिए फ़ॉरफ़ॉर्म और रिप्लाई फ़ील्ड प्राप्त किए गए हैं ताकि इसके लिए अतिरिक्त कॉल की आवश्यकता न हो। लेकिन उन्हें ChatMessageUI में बदलने से पुनरावृत्ति हो जाएगी, यानी कॉल काउंट का प्रदर्शन बहुत बढ़ सकता है। जैसा कि हमने पहले उल्लेख किया है, मान लें कि हमारे पास बहुत अधिक नेस्टिंग नहीं है और श्रृंखला तीन संदेशों तक सीमित है।

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

पेशेवरों:

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

कम:

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

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

Naive समानांतर प्रसंस्करण

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

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

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 एस पर लौट आएंगे।

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


पेशेवरों:

1. समवर्ती संदेश प्रसंस्करण का आसान कार्यान्वयन।
2. अच्छा स्केलेबिलिटी।

विपक्ष:

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

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

कैशिंग

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

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

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

पेशेवरों:

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

विपक्ष:

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

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

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

परिणाम

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

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

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

दो मुख्य क्षेत्र हैं जिनमें आप समाधान खोज सकते हैं:

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

बंडलों का इज़ाफ़ा कोड को समकालिक रखते हुए बाहरी कॉल की संख्या को बहुत कम कर देगा। लेख का अगला भाग इस विषय के लिए समर्पित होगा।