पिंग से प्राप्त डेटा: यह गोल यात्रा या एक तरीका है?

Question

मेरे पास 2 सर्वर हैं, प्रत्येक दो अलग-अलग स्थानों में हैं। मुझे एक पर एक एप्लिकेशन होस्ट करने की आवश्यकता है, और दूसरे पर डेटाबेस सर्वर।

ऐप सर्वर से, यदि मैं डेटाबेस सर्वर को पिंग करता हूं, तो औसतन मुझे लगभग 30ms मिलते हैं।

मेरा सवाल यह है कि:

When I query the database from the app;

क्या यह लेने जा रहा है 30 ms + database_server_query_run_time

या;

क्या यह + 30ms लेने वाला है30 ms + database_server_query_run_time

मैं इसे समझना चाहूंगा।

Answer 1

यह आमतौर पर उन दो विकल्पों में और अधिक ले जाएगा।

पिंग क्लाइंट से सर्वर तक समय को मापता है, और फिर से वापस (आरटीटी - राउंड ट्रिप टाइम)

आमतौर पर डेटाबेस टीसीपी का उपयोग करते हैं, इसलिए आपको सबसे पहले टीसीपी हैंडशेक शुरू करने के लिए एक SYN पैकेट भेजने की जरूरत है (चलो कहते हैं कि 15ms * + cpu समय को सरल बनाने के लिए, फिर आप पुनः प्राप्त करें और SYN / ACK (15ms + cpu समय), एक ACK और एक वापस भेजें) अनुरोध (कम से कम 15ms + cpu समय), फिर DB के लिए क्वेरी को संसाधित करने का समय, और फिर समय (15ms + cpu) डेटा वापस पाने के लिए, और थोड़ा अधिक ack करने के लिए, और कनेक्शन को बंद करें।

यह डेटाबेस के लिए प्रमाणीकरण (उपयोगकर्ता नाम / पासवर्ड) की गिनती नहीं है, और कोई एन्क्रिप्शन (एसएसएल हैंडशेक / डीएच या जो कुछ भी आवश्यक है) नहीं है।

* एक दौर यात्रा के समय का आधा, वहां और पीछे के मार्ग को मानते हुए सममित है (आधा समय वहां पहुंचने के लिए और आधा वापस पाने के लिए ... पिंग उत्तर के लिए सीपीयू प्रसंस्करण समय बहुत कम है)

Comments

लगातार टीसीपी सत्रों के साथ तीन-तरफा-हैंडशेक की समस्या का सामना किया जा सकता है।

— १२:०५ पर मिचेल्लनिक

@ मिचेलनिक, क्या आप कृपया विस्तार से बता सकते हैं? मैं वास्तव में इस पूरी बात को समझना चाहूंगा और डीबी को क्वेरी करने के लिए विलंबता को कम करने का सबसे अच्छा तरीका ढूंढूंगा।

— फिल

अफसोस की बात है, अधिकांश सॉफ्टवेयर (कम से कम वेब ऐप्स) न तो इसका समर्थन करते हैं: / लेकिन विचार यह है कि, DB को कनेक्शन (एक बार) स्थापित करने के लिए, और कनेक्शन को चालू (खुला) रखें, और बस एक से अधिक प्रश्न / उत्तर प्राप्त करते रहें। लगातार खुला कनेक्शन। यह हर बार tcp हैंडशेक, प्रमाणीकरण, आदि की आवश्यकता को समाप्त करता है।

— मुलज़

mulaz, समझाने के लिए धन्यवाद। मैं अजगर के साथ काम कर रहा हूँ, इसलिए हम देखेंगे कि यह कैसे जाता है। ;-)

— फिल

अनुरोध और उत्तर के आकार को न भूलें। उदाहरण के लिए, 1MB / सेकंड लिंक पर, 100KB पेलोड परिवहन के लिए एक अतिरिक्त 100ms ले जाएगा।

— डस्टिन बोसवेल

Answer 2

पिंग टाइम राउंड ट्रिप है। यदि आप इसके बारे में सोचते हैं - तो यह एक तरह से समय को कैसे माप सकता है? तो यह 30ms प्लस क्वेरी समय लगेगा।

Comments

मैं सिर्फ इतना जोड़ूंगा कि शायद 30 सेकंड + क्वेरी समय से थोड़ा अधिक समय लगेगा। चूंकि पिंग आईसीएमपी है और आपका डीबी कनेक्शन टीसीपी है, इसलिए आपके पास सेटअप / हैंडशेक, और डीबी कनेक्शन दीक्षा आदि भी होंगे

— दून

@ डून: जिसे लगातार टीसीपी / डेटाबेस कनेक्शन के साथ "टाला जा सकता है"

— मिचेल्निक

@ मिचेलनिक, क्या आपको लगता है कि लगातार DB कनेक्शन यहाँ जाने का रास्ता है? क्या यह कुछ अन्य मुद्दों का कारण होगा?

— फिल

@ मिखुएलनिक, निश्चित रूप से। सिर्फ इशारा कर रहा था कि यह RTT + Query जितना आसान नहीं है। विलंबता, आदि के कारण प्रति सत्र अधिकतम गति की सीमाएं भी हैं।)

— दून

@phil ज्यादातर मामलों में यह लगातार DB कनेक्शन फायदेमंद है, अगर आप कई सवाल करने जा रहे हैं। यदि प्रश्न फैल गए हैं / छिटपुट आप अनावश्यक रूप से संसाधनों को बांध रहे हैं, लेकिन यदि प्रश्न हर समय आ रहे हैं, आदि, तो आप प्रत्येक अनुरोध पर एक नया खोलने के विपरीत मौजूदा कनेक्शन का पुन: उपयोग करके ओवरहेड की एक गैर तुच्छ राशि बचाएंगे।

— दून