http HEAD बनाम प्रदर्शन प्राप्त करें

Question

मैं एक आरईएसटी वेब सेवा स्थापित कर रहा हूं जिसे जल्द से जल्द YES या NO का उत्तर देने की आवश्यकता है।

एक हेड सेवा डिजाइन करना ऐसा करने का सबसे अच्छा तरीका प्रतीत होता है लेकिन मैं जानना चाहता हूं कि मुझे वास्तव में जीईटी अनुरोध करने के दौरान कुछ समय मिलेगा या नहीं।

मुझे लगता है कि मुझे बॉडी स्ट्रीम प्राप्त होता है जो मेरे सर्वर पर खुला/बंद नहीं होता है (लगभग 1 मिलीसेकंड?)। चूंकि बाइट्स लौटने की मात्रा बहुत कम है, क्या मुझे आईपी पैकेट नंबर में परिवहन में कोई समय मिलता है?

आपकी प्रतिक्रिया के लिए अग्रिम धन्यवाद!

संपादित करें:

आगे संदर्भ की व्याख्या करने के लिए:

• मैं, कुछ प्रक्रियाओं को क्रियान्वित करने में यदि वे एक सक्रिय स्थिति में हैं बाकी सेवाओं का एक सेट है।
• मेरे पास एक और आरईएसटी सेवा है जो इन सभी पहली सेवाओं की स्थिति का संकेत देती है।

चूंकि उस अंतिम सेवा को अक्सर ग्राहकों के एक बहुत बड़े सेट (एक कॉल प्रत्येक 5ms की उम्मीद है) द्वारा अक्सर बुलाया जाएगा, तो मैं सोच रहा था कि एक हेड विधि का उपयोग करना एक मूल्यवान अनुकूलन हो सकता है? प्रतिक्रिया शरीर में लगभग 250 वर्ण वापस आते हैं। हेड विधि कम से कम इन 250 वर्णों का परिवहन प्राप्त करती है, लेकिन यह प्रभाव क्या है?

मैं बेंचमार्क के लिए दो विधियों (सिर प्राप्त बनाम) के बीच अंतर करने की कोशिश की, 1000 बार कॉल चल रहा है, लेकिन सभी में कोई लाभ (< 1ms) देखें ...

Answer 1

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

आप दोनों विकल्पों को लागू कर सकते हैं और उन्हें तेजी से देखने के लिए बेंचमार्क कर सकते हैं, लेकिन माइक्रो-ऑप्टिमाइज़ करने के बजाय, मैं आदर्श आरईएसटी इंटरफेस को डिजाइन करने पर ध्यान केंद्रित करूंगा। एक स्वच्छ आरईएसटी एपीआई आमतौर पर क्लडजी एपीआई की तुलना में लंबे समय तक अधिक मूल्यवान होती है जो तेजी से हो सकती है या नहीं भी हो सकती है। मैं HEAD के उपयोग को हतोत्साहित नहीं कर रहा हूं, बस यह सुझाव दे रहा हूं कि यदि आप "सही" डिज़ाइन हैं तो आप इसका उपयोग केवल तभी करेंगे।

यदि आपको जो जानकारी चाहिए वह वास्तव में संसाधन के बारे में मेटा डेटा है जिसे HTTP शीर्षलेखों में अच्छी तरह से प्रदर्शित किया जा सकता है या यह जांचने के लिए कि संसाधन मौजूद है या नहीं, HEAD अच्छी तरह से काम कर सकता है।

उदाहरण के लिए, मान लीजिए कि आप जांचना चाहते हैं कि संसाधन 123 मौजूद है या नहीं। एक 200 का मतलब है "हाँ" और एक 404 का मतलब है "नहीं":

HEAD /resources/123 HTTP/1.1 
[...] 

HTTP/1.1 404 Not Found 
[...] 

हालांकि, अगर "हाँ" या "नहीं" आप अपने बाकी सेवा से चाहते हैं संसाधन ही है, का एक हिस्सा नहीं बल्कि मेटा डेटा की तुलना में है , आपको GET का उपयोग करना चाहिए।

Answer 2

आपका प्रदर्शन शायद ही उपयोग करके बदल जाएगा एक जीईटी अनुरोध के बजाय एक HEAD अनुरोध।

इसके अलावा जब आप इसे पूर्ण-पूर्ण होना चाहते हैं और आप डेटा प्राप्त करना चाहते हैं तो आपको एक HEAD अनुरोध के बजाय एक GET अनुरोध का उपयोग करना चाहिए।

Answer 3

आप प्रदर्शन को मापने के लिए आसानी से एक छोटा परीक्षण कर सकते हैं। मुझे लगता है कि प्रदर्शन अंतर लापरवाह होगा, क्योंकि यदि आप केवल शरीर में 'वाई' या 'एन' लौट रहे हैं, तो यह एक अतिरिक्त बाइट है जो पहले से ही खुली धारा में संलग्न है।

मैं जीईटी के साथ भी जाऊंगा क्योंकि यह अधिक सही है। आपको HTTP हेडर में सामग्री वापस नहीं करना है, केवल मेटाडाटा।

Answer 4

मुझे 'बॉडी स्ट्रीम खुली/बंद' की आपकी चिंता को समझ में नहीं आता है। प्रतिक्रिया निकाय http प्रतिक्रिया हेडर के समान स्ट्रीम पर होगा और दूसरा कनेक्शन नहीं बनाएगा (जिस तरह से 3-6ms की सीमा में अधिक है)।

ऐसा कुछ ऐसा पूर्व-परिपक्व अनुकूलन प्रयास जैसा लगता है जो केवल एक महत्वपूर्ण या यहां तक ​​कि मापनीय अंतर नहीं बनाएगा। वास्तविक अंतर सामान्य रूप से आरईएसटी के साथ अनुरूपता है, जो डेटा प्राप्त करने के लिए जीईटी का उपयोग करने की सिफारिश करता है ..

मेरा उत्तर नहीं है, अगर यह समझ में आता है तो जीईटी का उपयोग करें, हेड का उपयोग करके कोई प्रदर्शन लाभ नहीं है।

Answer 5

मैं दृढ़ता से इस तरह के दृष्टिकोण को हतोत्साहित करता हूं।

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

और याद रखें: प्रारंभिक अनुकूलन सभी बुराइयों की जड़ है।

Answer 6

मुझे यह प्रश्न मिला जब अनुरोधकर्ता ने पूछा। मैं भी http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html पर इस पाया:

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

ऐसा लगता है कि अनुरोधकर्ता के प्रश्न का सही उत्तर यह है कि यह आरईएसटी प्रोटोकॉल द्वारा प्रस्तुत किए जाने वाले पर निर्भर करता है। उदाहरण के लिए, मेरे विशेष मामले में, मेरे आरईएसटी प्रोटोकॉल का उपयोग काफी बड़े (10k से अधिक में) छवियों को पुनः प्राप्त करने के लिए किया जाता है। यदि मेरे पास निरंतर आधार पर ऐसे संसाधनों की बड़ी संख्या जांच की जा रही है, और यह देखते हुए कि मैं अनुरोध शीर्षलेखों का उपयोग करता हूं, तो यह w3.org की सिफारिशों के अनुसार, HEAD अनुरोध का उपयोग करने के लिए समझ में आता है।

Answer 7

सिर + शरीर प्राप्त करने के लिए, सिर केवल सिर लाता है। यह राय का विषय नहीं होना चाहिए जो कि तेज़ है। मैं ऊपर उल्लिखित उत्तरों को कम नहीं करता हूं। यदि आप हेड के लिए जाने की तुलना में मेटा जानकारी की तलाश में हैं, जो इस उद्देश्य के लिए है।