मुझे MySQL संपीड़ित प्रोटोकॉल का उपयोग कब करना चाहिए?

Question

मैंने सीखा है कि MySQL सर्वर और ग्राहकों के बीच संचार को संपीड़ित कर सकता है।

संपीड़न अगर दोनों क्लाइंट और सर्वर समर्थन zlib संपीड़न, और ग्राहक संपीड़न का अनुरोध करता है प्रयोग किया जाता है।

(MySQL Forge Wiki से)

सबसे स्पष्ट पक्ष-विपक्ष रहे

• पेशेवरों: कम पेलोड आकार
• विपक्ष: बढ़ी हुई गणना समय

तो, संकुचित है जब भी मैं पर्याप्त चश्मा वाले सर्वरों को बर्दाश्त कर सकता हूं तो प्रोटोकॉल कुछ सक्षम होना चाहिए? क्या मुझे अन्य कारकों पर विचार करना चाहिए?

Answer 1

प्रदर्शन लाभ बड़े पैमाने पर परिणाम के आकार पर निर्भर होने जा रहे हैं सेट है कि आप, भेज रहे हैं नेटवर्क बैंडविड्थ और डेटाबेस सर्वर और अपने ग्राहकों के बीच विलंबता के अलावा।

बड़ा परिणाम सेट, बड़ा विलंबता, या कम बैंडविड्थ, उतनी ही अधिक संपीड़न के लाभ देखेंगे।

आपकी अधिकतम सेवा सेवा सबसे छोटी बाधा तक ही सीमित है। इसलिए, आपको विश्लेषण करना होगा कि आप वर्तमान में नेटवर्क और सीपीयू संसाधनों के संबंध में कहां हैं।

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

आप बैंडविड्थ के लिए भुगतान करते हैं, बैंडविड्थ के लिए व्यापार CPU उपयोग आसानी से उचित है, और भले ही आप कहीं भी नहीं बैंडविड्थ टोंटी तक पहुँचने के पास, कि तेज गति, और सेवा के उच्च स्तर, कुछ के लायक है।

भूल जाते हैं कि ग्राहक भी CPU चक्र व्यय करना होगा डेटा को संपीड़ित करें। एक बड़ा मुद्दा नहीं है, लेकिन अभी भी एक कारक है। आम तौर पर, आज के सीपीयू आज के नेटवर्क से तेज हैं।

Answer 2

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

मैं कहूंगा कि जब तक आपका डीबी और ऐप/वेब सर्वर भौगोलिक रूप से अलग नहीं होते हैं (यानी एक ही सर्वर या नेटवर्क पर नहीं), तो संपीड़न को सक्षम करने में बहुत कम लाभ होगा।

Answer 3

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

यदि आप एक ही मशीन पर एक MySQL सर्वर क्वेरी, या यहाँ तक कि एक ही नेटवर्क पर मैं बहुत बिंदु संपीड़न सक्षम करने नहीं दिख रहा।

Answer 4

मैं जानता हूँ कि यह देर हो चुकी है, लेकिन मैं हालांकि मैं इस का हिस्सा हो सकता है:

• Large result sets vs compression

ऐसा लगता है कि 100 Mbit लिंक (1.4 एमएस राउंड ट्रिप समय के साथ) है पर्याप्त तेज़ ... संपीड़न के साथ, 127 अनुक्रमण से कुल अनुक्रमण समय 87 सेकंड तक घटा दिया गया। कुल रन टाइम में यह लगभग 1.5x सुधार है। MySQL क्वेरी समय सुधार भी अधिक है। दूसरी ओर 1 जीबीटी लिंक पर्याप्त तेज़ था; और कुल रन टाइम संपीड़न के साथ 1.2x गुना अधिक खराब था।

जब तक आपका डेटाबेस और क्लाइंट एक ही मशीन पर न हो, 100 एमबीआईटी नेटवर्क और धीमी गति से, संपीड़न को सक्षम करें!

हालांकि, अपने अंतिम निर्णय भी CPU चक्र (/ सेक दबाव हटाना) और बैंडविड्थ उपयोग (तार पर और अधिक डेटा) की लागत के बीच संतुलन पर निर्भर हो सकता है।