http HEAD เทียบกับรับประสิทธิภาพ

111

ฉันกำลังตั้งค่าบริการเว็บ REST ที่ต้องตอบว่าใช่หรือไม่ใช่โดยเร็วที่สุด

การออกแบบบริการ HEAD ดูเหมือนจะเป็นวิธีที่ดีที่สุด แต่ฉันต้องการทราบว่าฉันจะมีเวลามากขึ้นหรือไม่เมื่อเทียบกับการร้องขอ GET

ฉันคิดว่าฉันได้รับ body stream เพื่อไม่ให้เปิด / ปิดบนเซิร์ฟเวอร์ของฉัน (ประมาณ 1 มิลลิวินาที?) เนื่องจากจำนวนไบต์ที่จะส่งคืนนั้นต่ำมากฉันจะได้รับเวลาในการขนส่งในหมายเลขแพ็คเก็ต IP หรือไม่?

ขอบคุณล่วงหน้าสำหรับคำตอบของคุณ!

แก้ไข:

เพื่ออธิบายบริบทเพิ่มเติม:

ฉันมีชุดบริการ REST ที่ดำเนินการบางกระบวนการหากอยู่ในสถานะใช้งานอยู่
ฉันมีบริการ REST อื่นที่ระบุสถานะของบริการแรกทั้งหมดเหล่านี้

เนื่องจากบริการสุดท้ายนั้นจะถูกเรียกใช้บ่อยมากโดยลูกค้าจำนวนมาก (คาดว่าจะมีการโทรหนึ่งครั้งทุกๆ 5 มิลลิวินาที) ฉันจึงสงสัยว่าการใช้เมธอด HEAD จะเป็นการเพิ่มประสิทธิภาพที่มีคุณค่าหรือไม่? มีการส่งคืนอักขระประมาณ 250 ตัวในเนื้อหาการตอบสนอง อย่างน้อยวิธี HEAD จะได้รับการขนส่ง 250 ตัวอักษรเหล่านี้ แต่ผลกระทบนั้นคืออะไร?

ฉันพยายามเปรียบเทียบความแตกต่างระหว่างสองวิธี (HEAD vs GET) เรียกใช้การโทร 1,000 ครั้ง แต่ไม่เห็นกำไรเลย (<1ms) ...

http get head

— Asterius
แหล่งที่มา

2

นอกจากนี้ยังขึ้นอยู่กับวิธีการที่คุณใช้ฝั่งเซิร์ฟเวอร์ โดยปกติเซิร์ฟเวอร์อาจใช้เวลาเท่ากันในการประมวลผลคำขอ GET หรือคำขอ HEAD เนื่องจากเซิร์ฟเวอร์อาจจำเป็นต้องทราบเนื้อหาขั้นสุดท้ายเพื่อคำนวณContent-Lengthค่าส่วนหัวซึ่งเป็นข้อมูลสำคัญในการตอบสนองของคำขอ HEAD ยกเว้นว่าจะมีวิธีการฝั่งเซิร์ฟเวอร์ที่ได้รับการปรับให้เหมาะสมมากกว่านี้ข้อดีเพียงอย่างเดียวคือแบนด์วิดท์จะถูกบันทึกและไคลเอนต์ไม่จำเป็นต้องแยกวิเคราะห์เนื้อหาการตอบสนอง โดยพื้นฐานแล้วการเพิ่มประสิทธิภาพจะขึ้นอยู่กับการใช้งานทั้งเซิร์ฟเวอร์และไคลเอ็นต์

— itsjavi

173

RESTful URI ควรแสดงถึง "ทรัพยากร" ที่เซิร์ฟเวอร์ ทรัพยากรมักถูกจัดเก็บเป็นบันทึกในฐานข้อมูลหรือไฟล์บนระบบไฟล์ ยกเว้นกรณีที่ทรัพยากรที่มีขนาดใหญ่หรือช้าที่จะดึงที่เซิร์ฟเวอร์ที่คุณอาจไม่เห็นกำไรที่วัดได้โดยใช้แทนHEAD GETอาจเป็นไปได้ว่าการดึงข้อมูลเมตานั้นไม่ได้เร็วไปกว่าการดึงทรัพยากรทั้งหมด

คุณสามารถใช้ทั้งสองตัวเลือกและเปรียบเทียบเพื่อดูว่าตัวเลือกใดเร็วกว่า แต่แทนที่จะปรับให้เหมาะสมแบบไมโครฉันจะมุ่งเน้นไปที่การออกแบบอินเทอร์เฟซ REST ในอุดมคติ REST API ที่สะอาดมักจะมีคุณค่าในระยะยาวมากกว่า API kludgey ที่อาจเร็วกว่าหรือไม่ก็ได้ ฉันไม่ได้ท้อใจในการใช้งานHEADเพียงแค่แนะนำว่าคุณควรใช้หากเป็นการออกแบบที่ "ถูกต้อง" เท่านั้น

หากข้อมูลที่คุณต้องการจริงๆคือข้อมูลเมตาเกี่ยวกับทรัพยากรที่สามารถแสดงได้อย่างสวยงามในส่วนหัว HTTP หรือเพื่อตรวจสอบว่าทรัพยากรนั้นมีอยู่หรือไม่HEADอาจใช้งานได้ดี

ตัวอย่างเช่นสมมติว่าคุณต้องการตรวจสอบว่าทรัพยากร 123 มีอยู่หรือไม่ A 200หมายถึง "ใช่" และ404หมายถึง "ไม่":

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

HTTP/1.1 404 Not Found
[...]

แต่ถ้า "ใช่" หรือ "ไม่ใช่" คุณต้องการจากการให้บริการส่วนที่เหลือของคุณเป็นส่วนหนึ่งของทรัพยากรของตัวเองมากกว่าข้อมูล meta GETคุณควรใช้

— อังเดรดี
แหล่งที่มา

4

สิ่งที่ดีที่สุดมักจะเรียบง่ายเช่นเดียวกับคำตอบนี้ โวลา!

— Afzal SH

คำตอบที่ยอดเยี่ยม! ฉันมีคำถาม: แล้วการใช้มันเป็นtouchคำสั่งเพื่ออัพเดตจำนวนการดูโพสต์บนเซิร์ฟเวอร์ล่ะ? มีการดึงข้อมูลโพสต์ผ่านการ/postsโทรปกติแล้วดังนั้นฉันแค่ต้องการอัปเดตจำนวนการดูหลังจากที่ผู้ใช้โต้ตอบกับโพสต์ไม่ทางใดก็ทางหนึ่ง

— aalaap

1

@aalaap หากคุณกำลังจะอัปเดตตัวนับการดูสำหรับHEADคำขอคุณควรทำเช่นนั้นสำหรับGETคำขอด้วย การตัดสินใจที่จะใช้GETหรือHEADท้ายที่สุดขึ้นอยู่กับไคลเอนต์ HTTP HEADเซิร์ฟเวอร์ของคุณควรจะทำงานในลักษณะเดียวกันสำหรับทั้งสองประเภทคำขอยกเว้นไม่มีการตอบสนองของร่างกายเมื่อการตอบสนองต่อ สำหรับวิธีนี้เป็นวิธีที่ดีในการใช้สิ่งต่างๆเช่นตัวนับมุมมองหรือไม่ฉันไม่แน่ใจ

— Andre D

-1 ข้อมูลใด ๆ ที่สามารถตั้งชื่อสามารถเป็นทรัพยากรได้ ดังนั้น Uniform Resource Locator แนวคิดที่ว่าการใช้ส่วนหนึ่งของโปรโตคอล HTTP ตามที่ออกแบบไว้คือ "kludgey" หรือ "ไม่สะอาด" เป็นเรื่องแปลกประหลาด

— Fraser

1

@ สิทธารถะนั้นมักจะจริง แต่ก็ไม่เสมอไป สามารถละเว้นเมื่อใช้Content-Length Transfer-Encoding: chunkedแม้Content-Lengthจะเป็นไปได้ว่าเซิร์ฟเวอร์สามารถรับขนาดทรัพยากรและข้อมูลเมตาอื่น ๆ ที่ใช้ในส่วนหัวได้โดยไม่ต้องดึงทรัพยากรจริง บางทีข้อมูลเมตานั้นอาจถูกแคชไว้ในหน่วยความจำเพื่อให้เข้าถึงได้อย่างรวดเร็ว นั่นคือทั้งหมดที่เฉพาะเจาะจงในการใช้งาน

— Andre D

39

ฉันพบคำตอบนี้เมื่อมองหาคำถามเดียวกับที่ผู้ร้องขอถาม ฉันพบสิ่งนี้ที่http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html :

เมธอด HEAD เหมือนกับ GET ยกเว้นว่าเซิร์ฟเวอร์ต้องไม่ส่งคืนข้อความ - เนื้อหาในการตอบสนอง ข้อมูลเมตาที่มีอยู่ในส่วนหัว HTTP เพื่อตอบสนองต่อคำขอ HEAD ควรจะเหมือนกับข้อมูลที่ส่งเพื่อตอบสนองต่อคำขอ GET วิธีนี้สามารถใช้สำหรับการรับข้อมูลเมตาเกี่ยวกับเอนทิตีโดยนัยโดยคำขอโดยไม่ต้องถ่ายโอนตัวเอนทิตีเอง วิธีนี้มักใช้ในการทดสอบลิงก์ไฮเปอร์เท็กซ์เพื่อความถูกต้องความสามารถในการเข้าถึงและการแก้ไขล่าสุด

สำหรับฉันแล้วดูเหมือนว่าคำตอบที่ถูกต้องสำหรับคำถามของผู้ร้องขอคือขึ้นอยู่กับสิ่งที่แสดงโดยโปรโตคอล REST ตัวอย่างเช่นในกรณีเฉพาะของฉันโปรโตคอล REST ของฉันถูกใช้เพื่อดึงภาพที่มีขนาดใหญ่พอสมควร (เช่นเดียวกับมากกว่า 10K) หากฉันมีการตรวจสอบทรัพยากรดังกล่าวจำนวนมากอย่างสม่ำเสมอและเนื่องจากฉันใช้ประโยชน์จากส่วนหัวของคำขอดังนั้นจึงควรใช้คำขอ HEAD ตามคำแนะนำของ w3.org

— ชาร์ลส์โทมัส
แหล่งที่มา

15

ฉันไม่แนะนำวิธีการแบบนี้

บริการ RESTful ควรเคารพความหมายของคำกริยา HTTP คำกริยา GET มีไว้เพื่อดึงเนื้อหาของทรัพยากรในขณะที่คำกริยา HEAD จะไม่ส่งคืนเนื้อหาใด ๆ และอาจถูกใช้ตัวอย่างเช่นเพื่อดูว่าทรัพยากรมีการเปลี่ยนแปลงหรือไม่เพื่อทราบขนาดหรือประเภทของทรัพยากรเพื่อตรวจสอบว่า มีอยู่และอื่น ๆ

และอย่าลืมว่าการเพิ่มประสิทธิภาพในช่วงต้นเป็นรากเหง้าของความชั่วร้าย

— Eric Citaire
แหล่งที่มา

9

ดึงหัว + ลำตัว HEAD ดึงหัวเท่านั้น ไม่ควรมโนว่าอันไหนเร็วกว่ากัน ฉันไม่ปฏิเสธคำตอบที่ได้รับการโหวตข้างต้น หากคุณกำลังมองหาข้อมูล META แทนที่จะไปที่ HEAD ซึ่งมีไว้เพื่อจุดประสงค์นี้

— วิคเตอร์โจราส
แหล่งที่มา

8

ประสิทธิภาพของคุณแทบจะไม่เปลี่ยนแปลงโดยใช้คำขอ HEAD แทนคำขอ GET

นอกจากนี้เมื่อคุณต้องการให้ REST-ful และคุณต้องการรับข้อมูลคุณควรใช้คำขอ GET แทนคำขอ HEAD

— jabbink
แหล่งที่มา

3

ฉันไม่เข้าใจความกังวลของคุณเกี่ยวกับ 'สตรีมเนื้อหาถูกเปิด / ปิด' เนื้อหาตอบสนองจะอยู่บนสตรีมเดียวกับส่วนหัวการตอบกลับ http และจะไม่สร้างการเชื่อมต่อที่สอง (ซึ่งโดยปกติแล้วจะอยู่ในช่วง 3-6ms มากกว่า)

ดูเหมือนว่าจะเป็นความพยายามในการปรับให้เหมาะสมก่อนวัยอันควรสำหรับบางสิ่งที่จะไม่สร้างความแตกต่างอย่างมีนัยสำคัญหรือวัดผลได้ ความแตกต่างที่แท้จริงคือความสอดคล้องกับ REST โดยทั่วไปซึ่งแนะนำให้ใช้ GET เพื่อรับข้อมูล ..

คำตอบของฉันคือไม่ใช้ GET ถ้ามันสมเหตุสมผลไม่มีการเพิ่มประสิทธิภาพโดยใช้ HEAD

— Smassey
แหล่งที่มา

สมมติว่าเนื้อหามีขนาด 100MB แน่นอนว่าหัวจะน้อยกว่าเนื้อหาที่มีขนาด ตอนนี้เมื่อเราขอทรัพยากรนั้นโดยวิธี GET หรือ HEAD ในความคิดของคุณไม่มีความแตกต่างด้านประสิทธิภาพหรือไม่!

— Mohammad Afrashteh

3

OP ระบุ 250 ตัวอักษรในเนื้อหาของการตอบสนอง ไม่ใช่ 100MB. นั่นเป็นคำถามที่แตกต่างกันโดยสิ้นเชิง

— smassey

2

คำขอHEADก็เหมือนกับคำขอGETยกเว้นเนื้อหาของการตอบกลับว่างเปล่า คำขอประเภทนี้สามารถใช้ได้เมื่อสิ่งที่คุณต้องการคือข้อมูลเมตาเกี่ยวกับไฟล์ แต่ไม่จำเป็นต้องส่งข้อมูลทั้งหมดของไฟล์

— Shadab Ali
แหล่งที่มา

-1

คุณสามารถทำการทดสอบเล็กน้อยเพื่อวัดประสิทธิภาพด้วยตัวคุณเองได้อย่างง่ายดาย ฉันคิดว่าความแตกต่างของประสิทธิภาพน่าจะเป็นเรื่องเล็กน้อยเพราะถ้าคุณส่งคืนเฉพาะ "Y" หรือ "N" ในร่างกายมันจะเป็นไบต์พิเศษเดียวที่ต่อท้ายสตรีมที่เปิดอยู่แล้ว

ฉันจะไปกับ GET ด้วยเพราะถูกต้องกว่า คุณไม่ควรส่งคืนเนื้อหาในส่วนหัว HTTP แต่เป็นข้อมูลเมตาเท่านั้น

— Ashleys สมอง
แหล่งที่มา

รับ - ไม่ใช่แค่ "ไบต์พิเศษเดี่ยว" ที่ลึกลับเท่านั้น แค่ทั้งตัว! ในกรณีของเอกสารขนาดใหญ่อาจมีขนาดเป็นเมกะไบต์

— porfirion