Kafka के प्रदर्शन को बेहतर बनाने के सुझाव

linger.ms सेटिंग (डिफ़ॉल्ट 0ms) प्रोड्यूसर को बताती है कि बैच भेजने से पहले अधिक संदेशों के आने की कितनी देर प्रतीक्षा करनी है, भले ही batch.size पूरा न हुआ हो।

• बैचिंग को बेहतर बनाने के लिए यह batch.size के साथ काम करती है।
• एक छोटा धनात्मक मान (जैसे, 5-50ms) थ्रूपुट को काफ़ी बढ़ा सकता है।
• यह बैच में अधिक संदेश जमा होने देती है, जिससे नेटवर्क कॉल कम होती हैं।

इससे थोड़ी देरी होती है, लेकिन अक्सर थ्रूपुट और विलंबता के बीच बेहतर संतुलन मिलता है।

संदेश बैच को भेजने से पहले संपीड़ित करने पर नेटवर्क बैंडविड्थ का उपयोग और Kafka ब्रोकर पर डिस्क स्थान काफ़ी कम हो सकता है। compression.type प्रॉपर्टी इसे नियंत्रित करती है।

• प्रकार: snappy, lz4, gzip, zstd।
• snappy और lz4: संपीड़न और CPU दक्षता के बीच अच्छा संतुलन।
• gzip और zstd: अधिक संपीड़न अनुपात देते हैं, लेकिन अधिक CPU का उपयोग करते हैं।

अपनी नेटवर्क सीमाओं और उपलब्ध CPU संसाधनों के आधार पर चुनें।

उचित बफ़र प्रबंधन प्रोड्यूसर को अवरुद्ध होने से रोकता है और यह सुनिश्चित करता है कि बड़े संदेश भेजे जा सकें।

• buffer.memory (डिफ़ॉल्ट 32MB): भेजे जाने की प्रतीक्षा कर रहे प्रोड्यूसर रिकॉर्ड के लिए कुल मेमोरी। अधिक थ्रूपुट वाले अचानक बढ़े भार में अवरोध रोकने के लिए send() कॉल के दौरान इसे बढ़ाएँ।
• max.request.size (डिफ़ॉल्ट 1MB): प्रोड्यूसर द्वारा भेजे जाने वाले एकल अनुरोध (बैच) का अधिकतम आकार। सुनिश्चित करें कि इसमें आपके सबसे बड़े संदेश या संपीड़ित बैच समा सकें।

इन्हें अपने ऐप्लिकेशन के संदेशों की विशेषताओं के अनुरूप ट्यून करें।

कंज़्यूमर ब्रोकर से संदेश बैच में प्राप्त करते हैं। fetch.min.bytes सेटिंग (डिफ़ॉल्ट 1 बाइट) यह निर्धारित करती है कि फ़ेच अनुरोध के लिए ब्रोकर को कम-से-कम कितना डेटा लौटाना चाहिए।

• fetch.min.bytes बढ़ाएँ: कंज़्यूमर द्वारा किए जाने वाले फ़ेच अनुरोधों की संख्या कम होती है।
• लाभ: नेटवर्क का अतिरिक्त भार कम होता है और कंज़्यूमर थ्रूपुट बेहतर होता है।
• समझौता: कंज़्यूमर के अधिक डेटा जमा होने की प्रतीक्षा करने से विलंबता थोड़ी बढ़ सकती है।

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

fetch.max.wait.ms (डिफ़ॉल्ट 500ms) वह अधिकतम समय निर्दिष्ट करता है, जितनी देर ब्रोकर डेटा कंज़्यूमर को भेजने से पहले fetch.min.bytes के उपलब्ध होने की प्रतीक्षा करेगा। यह fetch.min.bytes के साथ काम करता है।

• अधिक मान ब्रोकर को उत्तर देने से पहले अधिक डेटा एकत्र करने देता है।
• इससे नेटवर्क राउंड ट्रिप कम होती हैं और थ्रूपुट और बेहतर होता है।
• इसका विलंबता पर सीधा प्रभाव पड़ता है, क्योंकि कंज़्यूमर को डेटा के लिए अधिक समय तक प्रतीक्षा करनी पड़ सकती है।

अपने लिए सर्वोत्तम संतुलन खोजने हेतु इन दोनों फ़ेच सेटिंग को साथ में समायोजित करें।

max.poll.records सेटिंग (डिफ़ॉल्ट 500) कंज़्यूमर की poll() विधि की एक कॉल में लौटाए जाने वाले रिकॉर्ड की अधिकतम संख्या निर्धारित करती है।

• संदेशों को बड़े बैच में संसाधित करने से ऐप्लिकेशन थ्रूपुट काफ़ी बेहतर हो सकता है।
• इससे बार-बार होने वाली poll() कॉल और कमिट ऑपरेशन का अतिरिक्त भार घटता है।
• आपके ऐप्लिकेशन को संदेशों के इन बड़े समूहों को कुशलता से संभालने के लिए डिज़ाइन किया जाना चाहिए।

इसे अपने ऐप्लिकेशन की प्रोसेसिंग क्षमता के आधार पर ट्यून करें।

जहाँ ऑफ़सेट को मैन्युअल रूप से कमिट करने पर बारीकी से नियंत्रण मिलता है, वहीं ट्यून किए गए ऑटो-कमिट (enable.auto.commit=true) और auto.commit.interval.ms का उपयोग कंज़्यूमर प्रबंधन को सरल बना सकता है।

• डिफ़ॉल्ट अंतराल 5000ms (5 सेकंड) है।
• कम अंतराल: विफलता की स्थिति में संदेशों को दोबारा संसाधित करने का जोखिम घटाता है (छोटी 'कम-से-कम-एक-बार' अवधि)।
• अधिक अंतराल: Kafka को भेजे जाने वाले कमिट अनुरोधों की आवृत्ति घटाता है, जिससे थ्रूपुट थोड़ा बेहतर हो सकता है, लेकिन संदेशों को दोबारा संसाधित करने का जोखिम बढ़ जाता है।

दोबारा प्रोसेसिंग के जोखिम और कमिट के अतिरिक्त भार के बीच समझौते पर विचार करें।

हमने प्रदर्शन को बेहतर बनाने के लिए Kafka उत्पादक और उपभोक्ता की कई महत्वपूर्ण कॉन्फ़िगरेशन का अध्ययन किया है:

• उत्पादक: संदेश भेजने को अनुकूलित करने के लिए batch.size, linger.ms, compression.type, buffer.memory और max.request.size को समायोजित करें।
• उपभोक्ता: संदेशों को कुशलतापूर्वक प्राप्त करने और संसाधित करने के लिए fetch.min.bytes, fetch.max.wait.ms और max.poll.records को समायोजित करें।

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