การคิดค่าพร็อกซีต่อคำขอ
การคิดต่อคำขอคือจ่ายตามคำขอไปเว็บไซต์ผ่านพร็อกซี โดยทั่วไปคุณซื้อแพ็กเกจคำขอ แล้วแอปใช้เมื่อเช็กหน้าหรือเก็บข้อมูล ยิ่งติดต่อเว็บไซต์บ่อย แพ็กเกจก็หมดเร็ว
รูปแบบราคาพร็อกซีนี้มีรายละเอียดสำคัญ คือหนึ่งหน้าหรือหนึ่งงานสำเร็จไม่ได้เท่ากับหนึ่งคำขอที่เสียเงินเสมอ เบราว์เซอร์อาจส่งหลายคำขอเพื่อเปิดหน้า และบริการมีกฎนับของตน ต่อไปนี้เป็นวิธีประมาณการใช้และเลือกแพ็กเกจให้เหมาะกับงาน
จ่ายค่าอะไร
คุณจ่ายตามจำนวนคำขอที่ผู้ให้บริการนับ อาจขายแพ็กเกจคงที่หรือคิดตามใช้ ราคามักระบุต่อหนึ่งพันหรือหนึ่งล้านคำขอเพื่อเทียบอัตราง่าย แต่ไม่ได้บอกว่าต้องจ่ายตอนซื้อเท่าไร เพราะแพ็กเกจเล็กสุดอาจมีคำขอมากกว่านั้น
คำว่า “คำขอ” เดียวกันอาจหมายถึงคนละบริการ พร็อกซีทั่วไปส่งคำขอของแอปไปเว็บไซต์และคืนคำตอบ แอปคุณโหลดหน้าและแยกข้อมูล ส่วน API เก็บข้อมูล ราคาอาจรวมการรันเบราว์เซอร์ จัดการข้อจำกัดเข้าถึง และเตรียมผลลัพธ์ การเทียบราคาคำขออย่างเดียวจึงไม่พอ ต้องรู้ว่าราคานั้นบริการทำอะไรให้
ราคานี้สะดวกกับงานตามกำหนด คุณอาจทราบจำนวนหน้าและความถี่แล้ว ขั้นต่อไปคือหาว่าแต่ละการตรวจใช้กี่คำขอ จึงประมาณแพ็กเกจรายเดือนและการใช้ที่จะเพิ่มเมื่อเพิ่มหน้าได้
ขนาดคำตอบไม่จำเป็นต้องกระทบราคา หากอัตราต่อคำขอเท่ากัน การดึงข้อมูลมากในคำตอบเดียวอาจราคาเท่าคำตอบเล็ก แต่ต้องตรวจสิ่งที่รวม เพราะอาจจำกัดแบนด์วิดท์ ขนาดคำตอบ หรือเวลาทำงาน การประมวลผลข้อมูลเพิ่มอาจมีค่าแยกด้วย
แพ็กเกจคำขอไม่ได้กำหนดจำนวน IP ที่ได้รับ เช่น บริการหมุนเวียนอาจให้เข้ากลุ่ม IP ผ่านจุดเชื่อมต่อร่วม การเปลี่ยน IP และคงที่อยู่ตลอดเซสชันขึ้นอยู่กับการตั้งค่าบริการ การเปลี่ยน IP เพียงอย่างเดียวไม่บอกว่าจะคิดกี่คำขอ
บริการนับอะไรเป็นหนึ่งคำขอ
เริ่มจากแยกคำขอออกจากการเชื่อมต่อ คำขอ HTTP ขอให้เว็บไซต์ทำบางอย่าง เช่น คืนหน้าหรือข้อมูล แล้วเว็บส่งคำตอบ การรับส่งข้อมูลสองทิศทางไม่ได้หมายความว่าต้องหักสองคำขอในตัวเอง หากจะนับเช่นนั้นต้องมีกฎคิดราคาแยก
การเชื่อมต่อเป็นช่องทางที่แอปสื่อสารกับเซิร์ฟเวอร์ หลายคำขอใช้ช่องเดิมได้ HTTP/1.1 ให้ใช้การเชื่อมต่อซ้ำ ส่วน HTTP/2 ให้หลายการแลกเปลี่ยนทำงานพร้อมกันบนช่องเดียว จำนวนคำขอ การเชื่อมต่อที่เปิด และการเชื่อมต่อที่ทำงานพร้อมกันจึงเป็นคนละค่าที่วัด
HTTPS เพิ่มรายละเอียดอีกอย่าง เมื่อผ่านพร็อกซี HTTP แอปมักส่งคำสั่ง CONNECT เพื่อสร้างทันเนลไปเว็บ คำขอถัดไปเดินทางภายในแบบเข้ารหัส พร็อกซีส่งข้อมูล แต่โดยปกติอ่านคำขอ HTTP รายครั้งไม่ได้ พร็อกซี SOCKS ก็ให้การเชื่อมต่อปลายทางเช่นกัน แต่ละการกระทำของแอปไม่จำเป็นต้องเปิดการเชื่อมต่อใหม่
ด้วยเหตุนี้ บางบริการใช้ “คำขอ” หมายถึงการเชื่อมต่อหรือเหตุการณ์อื่นที่เซิร์ฟเวอร์พร็อกซีนับได้ บางรายนับ HTTP รายคำขอหรือการเรียก API จำนวนในเครื่องมือนักพัฒนาเบราว์เซอร์จึงอาจต่างจากแดชบอร์ดผู้ให้บริการ การรองรับ HTTP, HTTPS หรือ SOCKS5 อย่างเดียวไม่กำหนดกฎนับ
ก่อนซื้อแพ็กเกจใหญ่ ให้ทดสอบเล็ก ๆ บันทึกจำนวนงานที่แอปทำสำเร็จกับจำนวนคำขอที่บริการหัก ใช้แอป โพรโทคอล และการตั้งค่าที่จะใช้จริง การทดสอบด้วยไคลเอนต์ HTTP ง่าย ๆ ไม่แสดงการใช้ของเบราว์เซอร์ที่โหลดสคริปต์และทรัพยากรหน้าอื่นด้วย
เหตุใดหนึ่งหน้าอาจใช้หลายคำขอ
การเปิดหน้ามักต้องใช้มากกว่าเอกสารหลัก เบราว์เซอร์โหลดสไตล์ สคริปต์ รูป และข้อมูลแยกกัน หน้าที่เปิดอาจติดต่อเซิร์ฟเวอร์ต่อเพื่ออัปเดต คำขอบางส่วนผ่านพร็อกซีด้วยตามการตั้งค่าแอป และคิดราคาอย่างไรขึ้นอยู่กับแผน
การตามเปลี่ยนเส้นทางเพิ่มคำขอ หากเว็บไซต์ตอบว่าหน้าอยู่ที่อื่น แอปที่ตั้งให้ตามจะส่ง HTTP อีกคำขอไปที่อยู่ใหม่ การดึงเอกสารด้วยไคลเอนต์ง่ายกับเปิดหน้าครบในเบราว์เซอร์จึงอาจใช้จำนวนต่างกัน จำนวน URL ในรายการยังไม่บอกว่าประมวลผลต้องใช้กี่คำขอ
API อาจทำตรงกันข้าม คือคำขอเดียวได้หลายระเบียน ในตัวอย่าง เบราว์เซอร์ส่งห้าคำขอเพื่อโหลดหน้าหูฟังพร้อมราคา แอปใช้พร็อกซีเดียวเรียก API แค็ตตาล็อกของร้านนั้นและได้ราคาสินค้าห้ารายการในครั้งเดียว นี่คือ API ของร้านที่ส่งข้อมูลสินค้า หากแบ่งแค็ตตาล็อกเป็นหน้า แต่ละหน้าต้องขอเพิ่ม บางครั้งเพิ่มจำนวนสินค้าต่อคำตอบได้ หาก API รองรับและคืนข้อมูลที่ต้องใช้ครบ
วิธีนี้ช่วยให้แพ็กเกจทำงานที่มีประโยชน์ได้มากขึ้น การโหลดหน้าครบซ้ำ ดึงข้อมูลที่เก็บแล้ว และตรวจราคาถี่เกินจำเป็นใช้โควตาเร็ว การดึงหลายสินค้าต่อครั้ง บันทึกผล และเลือกความถี่เหมาะสมลดคำขอสำหรับงานเดิม ภาระเท่าเดิมจึงใช้โควตาได้นานขึ้นภายในอายุแพ็กเกจ หรือใช้ตรวจสินค้ามากขึ้นแทน
ควรวัดการใช้ต่องานสำเร็จ เช่น ตรวจหนึ่งหน้า ดึงรายการครบ หรือตรวจองค์ประกอบที่ปรากฏหลังสคริปต์รัน ให้วัดทั้งลำดับที่ต้องทำเพื่อได้ผล รวมการโหลดเพิ่มที่พลาดได้ง่ายเมื่อนับเฉพาะ URL เริ่มต้น
รูปแบบราคานี้เหมาะกับงานใด
ติดตามตามกำหนด
การใช้คำขอผูกกับการตรวจประจำได้ แอปอาจติดตามความพร้อมหน้า การเปลี่ยนรายการสาธารณะ หรือผลค้นสำหรับพื้นที่ที่ต้องการ คุณทราบจำนวนเป้าหมายและความถี่ล่วงหน้า การทดสอบแสดงคำขอต่อการตรวจและช่วยประมาณยอดเดือน
ไม่ต้องตรวจทุกหน้าถี่เท่ากัน หากข้อมูลเปลี่ยนวันละครั้ง การตรวจทุกนาทีมักได้ข้อมูลเดิม เก็บการตรวจถี่ให้หน้าที่ต้องรู้การเปลี่ยนเร็ว เพื่อคงโควตาไว้สำหรับสิ่งที่จำเป็น
เก็บข้อมูลผ่าน API และไดเรกทอรี
การใช้ขึ้นอยู่กับวิธีที่เว็บไซต์ให้ข้อมูล หากหน้ารายการมีครบแล้ว ไม่จำเป็นต้องเปิดรายละเอียดทุกชิ้น เก็บคำขอเพิ่มสำหรับรายการข้อมูลขาดหรือระเบียนที่เปลี่ยนจากรอบก่อน ยิ่งได้ข้อมูลที่ต้องใช้มากในครั้งเดียว การเก็บทั้งหมดก็ใช้คำขอน้อยลง
ต้องนับสิ่งที่บริการทำด้วย API ค้นหาอาจคืนผลที่แยกแล้ว แต่พร็อกซีทั่วไปให้แอปดาวน์โหลดและประมวลผลเอง ปริมาณงานต่างกัน เมื่อเทียบราคาให้ดูคำตอบมีอะไรและคุณยังต้องทำอะไรเอง
ตรวจเว็บไซต์และตรวจด้วยเบราว์เซอร์
การตรวจทางเทคนิคมักมีลำดับชัด คือเปิดที่อยู่ ตรวจคำตอบ ตามเปลี่ยนเส้นทางเมื่อจำเป็น และเก็บผล หากที่อยู่ส่วนใหญ่จัดการคล้ายกัน การทดสอบช่วยประมาณการใช้ได้ง่ายขึ้น การตรวจเบราว์เซอร์อาจใช้มากกว่าเพราะพึ่งสคริปต์ รูป และองค์ประกอบหน้าที่ทำงาน
เลือกวิธีตรวจตามจุดประสงค์ ไคลเอนต์ง่ายมักพอสำหรับดูว่าหน้าตอบหรือไม่ แต่ทดสอบแบบฟอร์มชำระเงินต้องโหลดสิ่งที่ฟอร์มต้องใช้ การปิดไฟล์จำเป็นลดคำขอ แต่ผลจะไม่แสดงประสบการณ์ผู้ใช้จริง
ข้อผิดพลาดและการลองใหม่กระทบการใช้อย่างไร
คำขอที่ส่งไม่ได้คืนข้อมูลที่ต้องการเสมอ เว็บไซต์อาจคืนข้อผิดพลาด หน้าตรวจการเข้าถึง หรือหน้าอื่น แม้ HTTP 200 ก็ไม่รับประกันว่าแอปได้สิ่งที่ต้องการ เพราะสถานะแจ้งความสำเร็จระดับ HTTP แต่ต้องตรวจเนื้อหาแยก
กฎคิดค่าคำขอเหล่านี้ต่างกัน บางบริการนับที่ส่ง บางรายคิดเฉพาะคำตอบที่ผ่านนิยามสำเร็จ API แบบจัดการให้อาจรวมความพยายามภายในหลายครั้งในราคาคำตอบเดียว โหมดหรือคุณสมบัติเพิ่มอาจเปลี่ยนกฎ “จ่ายต่อคำขอ” จึงไม่เท่ากับ “จ่ายเฉพาะข้อมูลที่ดึงได้” โดยอัตโนมัติ
การลองใหม่ของแอปต่างจากการลองภายในบริการ เมื่อแอปส่งอีกครั้ง จะสร้างคำขอใหม่ แต่เมื่อบริการลองงานที่ส่งไว้แล้วซ้ำ ความพยายามนั้นอาจรวมในราคา ให้ทราบว่าความพยายามใดถูกหักจากแพ็กเกจ
ระหว่างทดสอบ จดสามจำนวนคืองานที่เริ่ม คำขอที่คิดเงิน และงานที่สำเร็จ ความสำเร็จขึ้นกับจุดประสงค์ งานเก็บข้อมูลต้องมีช่องที่ต้องการและข้อมูลใหม่พอ ส่วนการติดตามความพร้อม การตรวจพบอย่างถูกต้องว่าเว็บใช้งานไม่ได้ก็เป็นการตรวจที่เสร็จ
ตัวเลขนี้ช่วยเห็นต้นทุนจริง คำขอถูกอาจไม่คุ้มถ้าต้องลองคำตอบใหม่หรือตัดทิ้งตลอด บริการแพงกว่าอาจทำงานบางส่วนให้คุณ ควรเทียบค่าใช้จ่ายเพื่อได้ผลที่ต้องการ รวมงานที่แอปยังต้องทำ
คำนวณแพ็กเกจที่ต้องใช้อย่างไร
เริ่มนับงานที่วางแผนว่ามีกี่เป้าหมายและบ่อยเพียงใด แล้วเพิ่มคำขอที่เกินการดึงตามปกติ เช่น การลองซ้ำที่พบจากทดสอบ คำนวณกลุ่มหน้าที่ทำงานต่างกันแยก และแยกสำรองการเติบโตด้วย เพื่อไม่เพิ่มคำขอส่วนเดียวกันสองรอบ
พิจารณาตัวอย่างสมมติ แอปตรวจ URL 150 รายการ ทุก 30 นาที เป็นเวลา 30 วัน สมมติว่าตรวจปกติใช้หนึ่งคำขอตามแผนที่เลือก และการลองเพิ่มทำให้ยอดใช้เพิ่ม 5% ตัวเลขและราคาทั้งหมดเป็นสมมติ ไม่ใช่ผลทดสอบผู้ให้บริการหรือราคาของ ProxyCompass
| สิ่งที่นับ | การคำนวณ | คำขอ |
|---|---|---|
| การตรวจตามกำหนด | 150 ที่อยู่ × 48 ครั้งต่อวัน × 30 วัน |
216,000 |
| ความพยายามเพิ่ม | 216,000 × 5% |
10,800 |
| การใช้ที่คาด | 216,000 + 10,800 |
226,800 |
| แพ็กเกจที่เลือก | โควตาแพ็กเกจสมมติ | 250,000 |
| สำรองเหนือยอดประมาณ | 250,000 − 226,800 |
23,200 |
แพ็กเกจที่เลือกเหลือสำรอง 23,200 คำขอ ใช้รองรับงานที่เพิ่มได้ขณะแพ็กเกจยังไม่หมดอายุ การลองใหม่ที่คาดรวมอยู่ในความพยายามเพิ่ม 10,800 แล้ว จึงไม่ควรนับสำรองนี้เป็นยอดใช้ของการลองเดิมอีกครั้ง
สมมติแพ็กเกจราคา $10 มี 250 พันคำขอ ราคาต่อพันตามหน่วยจึงเป็น $0.04 คุณจ่าย $10 สำหรับทั้งแพ็กเกจ การนำยอดคาด 226,800 คำขอ คูณอัตรานั้นได้ $9.072 นี่เป็นมูลค่าส่วนที่ใช้ ไม่ใช่ยอดซื้อ แพ็กเกจคงที่ยังราคา $10
สมมติว่าหลังการลองเพิ่ม แอปทำการตรวจตามกำหนดสำเร็จครบ 216,000 ครั้ง ต้นทุนหนึ่งพันการตรวจสำเร็จประมาณ $0.0463 จาก $10 ÷ 216,000 × 1,000 ค่านี้รวมคำขอเพิ่มและสำรองที่ซื้อ หากสำเร็จน้อยกว่านี้ ให้หารค่าใช้จ่ายด้วยจำนวนที่สำเร็จจริง
งานอื่นคำนวณแบบเดียวกัน หากคิดตามใช้ ให้นำคำขอที่คิดเงินคูณอัตราโดยเผื่อว่าอัตรานั้นครอบคลุมกี่คำขอ หากซื้อแพ็กเกจให้ใช้ราคาซื้อเต็ม แล้วหารด้วยงานที่สำเร็จ หากหลายโครงการใช้ร่วมกัน ให้กำหนดวิธีแบ่งต้นทุนระหว่างโครงการ
ตรวจด้วยว่าแอปทำงานทันเวลาหรือไม่ ตัวอย่างต้องตรวจ 7,200 ครั้ง ต่อวัน เฉลี่ยเริ่มห้าครั้งต่อนาที คุณอาจเริ่มทั้ง 150 ครั้ง พร้อมกันทุกครึ่งชั่วโมง หรือกระจายตลอดช่วง ยอดแพ็กเกจเท่ากันหากแต่ละครั้งใช้จำนวนความพยายามตามสมมติ แต่ภาระตอนเริ่มต่างกัน ขีดจำกัดการเชื่อมต่อหรืออัตราคำขออาจทำให้ตารางแบบแรกทำไม่ได้ตามแผน
ลดคำขอที่ไม่จำเป็นอย่างไร
ลบที่อยู่ซ้ำและบันทึกผลระหว่างทำงาน หลังล้มเหลว แอปควรทำต่อจากจุดหยุด หากเริ่มรายการทั้งหมดใหม่ทุกครั้ง หน้าที่ประมวลผลแล้วใช้แพ็กเกจซ้ำ ควรเก็บว่างานใดเสร็จและงานใดยังต้องทำ
ใช้วิธีโหลดที่จำเป็นเพื่อได้ข้อมูล หากข้อความมีในคำตอบเซิร์ฟเวอร์แล้ว อาจไม่ต้องรันเบราว์เซอร์ หากข้อมูลปรากฏหลังสคริปต์ทำงาน ดาวน์โหลดธรรมดาอาจไม่พอ บริการเก็บข้อมูลอาจให้โหมดเบราว์เซอร์และคุณสมบัติเพิ่มใช้เครดิตมากหรือคิดอีกราคา หนึ่งเครดิตจึงไม่เท่ากับหนึ่งคำขอเสมอ
คำตอบเล็กลงไม่ได้ลดคำขอเสมอ หากนับการเรียก HTTP คำตอบสั้นอาจใช้เท่าคำตอบยาว หากจะลดจำนวน อาจตรวจข้อมูลไม่เปลี่ยนให้น้อยลง ใช้ผลที่บันทึก หรือดึงหลายระเบียนใน API ครั้งเดียว แต่ข้อมูลต้องใหม่พอสำหรับงาน
จำกัดการลองซ้ำและพิจารณาสาเหตุ หากเว็บไม่พร้อมชั่วคราวหรือขอให้ช้าลง การลองทันทีอาจได้คำตอบเดิมและเสียอีกคำขอ การพักหรือลดความถี่อาจช่วยกว่า ระวังการกระทำที่สร้างหรือเปลี่ยนข้อมูลเป็นพิเศษ โดยตรวจผลครั้งแรกก่อนส่งใหม่ คำตอบสูญหายไม่ได้หมายความว่าเซิร์ฟเวอร์ไม่ได้ทำอะไร
หลังเปลี่ยน ให้ตรวจทั้งผลลัพธ์และยอดใช้ จำนวนคำขออาจลดเพราะแอปเลิกทำบางส่วนของงาน การลดมีประโยชน์เมื่อยังได้ข้อมูลที่ต้องการครบและทันเวลาเท่าเดิมด้วยคำขอน้อยลง
สิ่งที่ควรตรวจเมื่อเลือกแผนราคา
ก่อนอื่นยืนยันว่าใช้กับเว็บและแอปได้ ชนิดพร็อกซี ประเทศ เซสชัน และการเข้าหน้าที่ต้องการผ่าน IP ที่ให้ล้วนสำคัญ จากนั้นเทียบงานที่รวม ใครโหลดหน้า รันเบราว์เซอร์ แยกข้อมูล และลองเมื่อผิดพลาด สิ่งนี้ช่วยอธิบายว่าทำไมสองบริการคิดราคาคำขอต่างกัน
ตรวจอายุแพ็กเกจ กฎเติม และคำขอที่ไม่ใช้ แพ็กเกจใหญ่ที่ราคาต่อคำขอต่ำคุ้มเมื่อใช้กับงานจำเป็นทันเวลา หากเหลือทิ้ง ต้นทุนต่องานสำเร็จอาจสูงกว่าแพ็กเกจเล็ก
เพื่อเปรียบเทียบ เลือกหน้าทั่วไปของโครงการ รวมหน้าที่มักมีปัญหา บันทึกเวลา คำขอ ผล และการตั้งค่าแอป การทดสอบนี้ชี้ขนาดแพ็กเกจ ต้นทุนงานโดยประมาณ และว่าจะเสร็จทันหรือไม่