Harga Proksi Per Permintaan

Apa yang Anda bayar

Anda membayar jumlah permintaan yang dihitung penyedia. Penyedia mungkin menjual paket tetap atau menagih sesuai penggunaan layanan. Harga sering ditampilkan per seribu atau per sejuta permintaan. Ini memudahkan perbandingan tarif, tetapi tidak menunjukkan jumlah yang harus dibayar saat checkout: paket terkecil mungkin memuat lebih banyak permintaan.

Kata yang sama, “permintaan”, dapat menjelaskan layanan berbeda. Proksi biasa meneruskan permintaan aplikasi ke situs dan mengembalikan responsnya. Aplikasi Anda memuat halaman dan mengekstrak data. Dengan API pengumpulan data, harga mungkin juga mencakup menjalankan browser, menangani pembatasan akses, dan menyiapkan hasil. Karena itu, membandingkan harga permintaan saja tidak cukup; Anda perlu mengetahui pekerjaan yang dilakukan layanan dengan harga tersebut.

Harga ini praktis untuk pekerjaan yang mengikuti jadwal. Anda mungkin sudah mengetahui jumlah halaman yang perlu diperiksa dan frekuensinya. Selanjutnya, cari tahu jumlah permintaan yang digunakan setiap pemeriksaan. Anda kemudian dapat memperkirakan paket yang dibutuhkan selama sebulan dan pertumbuhan penggunaan jika menambah halaman.

Ukuran respons belum tentu memengaruhi harga. Jika tarif mengenakan jumlah yang sama untuk setiap permintaan, mengambil lebih banyak data dalam satu respons mungkin berbiaya sama dengan mengambil respons kecil. Namun, periksa cakupan tarif: mungkin ada batas lebar pita, ukuran respons, atau waktu eksekusi. Pemrosesan data tambahan juga mungkin dikenai biaya terpisah.

Paket permintaan tidak menentukan jumlah alamat IP yang Anda terima. Layanan berotasi, misalnya, dapat menyediakan akses ke kumpulan IP melalui titik koneksi bersama. Pergantian IP dan pemeliharaan alamat selama sesi bergantung pada pengaturan layanan. Pergantian IP saja tidak menunjukkan jumlah permintaan yang akan ditagih.

Apa yang dihitung layanan sebagai satu permintaan

Mulailah dengan memisahkan permintaan dari koneksi. Permintaan HTTP meminta situs melakukan sesuatu, seperti mengembalikan halaman atau menyediakan data. Situs mengirim respons. Data yang berjalan dalam kedua arah tidak dengan sendirinya berarti dua permintaan harus dipotong. Itu memerlukan aturan penagihan terpisah.

Koneksi adalah saluran komunikasi aplikasi dengan server. Beberapa permintaan dapat menggunakan koneksi yang sama. HTTP/1.1 memungkinkan koneksi dipakai ulang, sedangkan HTTP/2 memungkinkan beberapa pertukaran berjalan melaluinya sekaligus. Karena itu, jumlah permintaan, koneksi yang dibuka, dan koneksi yang aktif pada saat bersamaan adalah pengukuran berbeda.

HTTPS menambahkan detail lain. Saat terhubung melalui proksi HTTP, aplikasi umumnya mengirim perintah CONNECT untuk membuat terowongan ke situs. Permintaan berikutnya berjalan di dalam terowongan dalam bentuk terenkripsi. Proksi meneruskan data, tetapi dalam penggunaan biasa tidak dapat membaca permintaan HTTP individual. Proksi SOCKS juga menyediakan koneksi ke tujuan; setiap tindakan aplikasi belum tentu memerlukan koneksi baru.

Karena itu, sebagian layanan menggunakan “permintaan” untuk menyebut koneksi atau peristiwa lain yang dapat dihitung server proksinya. Layanan lain menghitung permintaan HTTP individual atau panggilan API. Jumlah permintaan pada alat pengembang browser dapat berbeda dari penggunaan pada dasbor penyedia. Dukungan HTTP, HTTPS, atau SOCKS5 saja tidak menentukan aturan penghitungan.

Sebelum membeli paket besar, jalankan pengujian kecil. Catat jumlah tugas yang diselesaikan aplikasi dan jumlah permintaan yang dipotong layanan. Gunakan aplikasi, protokol, dan pengaturan yang sama dengan rencana penggunaan berikutnya. Pengujian dengan klien HTTP sederhana tidak menunjukkan penggunaan browser yang juga memuat skrip dan sumber daya halaman lain.

Mengapa satu halaman dapat menggunakan beberapa permintaan

Membuka halaman sering memerlukan lebih dari dokumen utamanya. Browser memuat gaya, skrip, gambar, dan data secara terpisah. Halaman terbuka dapat terus menghubungi server untuk pembaruan. Sebagian permintaan ini juga melewati proksi, tergantung pengaturan aplikasi. Cara penagihannya bergantung pada tarif.

Mengikuti pengalihan menambahkan permintaan. Jika situs merespons bahwa halaman berada pada alamat lain, aplikasi yang dikonfigurasi mengikuti pengalihan mengirim permintaan HTTP lain ke alamat tersebut. Karena itu, mengambil satu dokumen dengan klien sederhana dan membuka halaman lengkap di browser dapat menggunakan jumlah permintaan berbeda. Jumlah URL dalam daftar belum menunjukkan banyaknya permintaan yang diperlukan untuk memprosesnya.

API dapat bekerja sebaliknya: satu permintaan mungkin mengambil banyak rekaman. Dalam contoh ini, browser membuat lima permintaan untuk memuat halaman produk headphone beserta harganya. Aplikasi menggunakan proksi yang sama untuk memanggil API katalog peritel itu dan mengambil lima harga produk dalam satu permintaan. Ini adalah API peritel yang menyediakan data produk. Jika API mengembalikan katalog dalam beberapa halaman, setiap halaman memerlukan permintaan lain. Terkadang Anda dapat meningkatkan jumlah produk per respons, selama API mendukung pengaturan tersebut dan mengembalikan semua data yang dibutuhkan.

Pendekatan ini membantu memperoleh lebih banyak pekerjaan berguna dari paket. Memuat halaman lengkap berulang kali, mengambil data yang sudah disimpan, dan memeriksa harga lebih sering daripada perlu dapat cepat menghabiskan kuota. Mengambil beberapa produk per panggilan, menyimpan hasil, dan memilih frekuensi pemeriksaan yang sesuai mengurangi permintaan untuk pekerjaan yang sama. Pada beban kerja sama, kuota dapat bertahan lebih lama dalam masa berlaku paket; atau Anda dapat menggunakannya untuk memeriksa lebih banyak produk.

Mengukur penggunaan per tugas selesai membantu. Tugas itu mungkin memeriksa satu halaman, mengambil daftar lengkap, atau memeriksa elemen yang muncul setelah skrip berjalan. Ukur seluruh rangkaian yang diperlukan untuk mencapai hasil tersebut. Ini mencakup pemuatan halaman tambahan yang mudah terlewat ketika hanya menghitung URL awal.

Kegunaan model harga ini

Pemantauan terjadwal

Penggunaan permintaan dapat dikaitkan dengan pemeriksaan rutin. Aplikasi mungkin memantau ketersediaan halaman, perubahan daftar publik, atau hasil pencarian untuk wilayah yang diperlukan. Anda mengetahui jumlah sasaran dan frekuensi pemeriksaan terlebih dahulu. Pengujian menunjukkan jumlah permintaan setiap pemeriksaan dan membantu memperkirakan konsumsi bulanan.

Halaman berbeda tidak harus diperiksa sama sering. Jika informasi berubah sekali sehari, memeriksa setiap menit biasanya mengembalikan data yang sama. Pemeriksaan lebih sering dapat dikhususkan untuk halaman yang perubahannya perlu segera diketahui. Ini menjaga paket tetap tersedia bagi pengamatan yang Anda butuhkan.

Mengumpulkan data melalui API dan direktori

Penggunaan di sini bergantung pada cara situs menyediakan informasinya. Jika daftar sudah memuat semua yang Anda butuhkan, tidak perlu membuka setiap halaman detail. Permintaan tambahan dapat dikhususkan untuk item dengan data tidak lengkap atau rekaman yang berubah sejak proses sebelumnya. Semakin banyak data yang dibutuhkan diambil dalam satu panggilan, semakin sedikit permintaan untuk pengumpulan lengkap.

Anda juga perlu memperhitungkan pekerjaan layanan. API pencarian mungkin mengembalikan hasil yang sudah diurai, sedangkan proksi biasa menyerahkan pengunduhan dan pemrosesan kepada aplikasi Anda. Jumlah pekerjaan ini berbeda. Saat membandingkan harga, periksa isi respons dan hal yang masih perlu Anda lakukan sendiri.

Audit situs dan pemeriksaan browser

Audit teknis sering memiliki urutan jelas: buka alamat, periksa respons, ikuti pengalihan jika diperlukan, dan simpan temuan. Jika sebagian besar alamat ditangani serupa, pengujian memudahkan perkiraan penggunaan. Pemeriksaan browser mungkin memerlukan lebih banyak permintaan karena bergantung pada skrip, gambar, dan elemen halaman yang bekerja.

Pilih metode pemeriksaan sesuai tujuannya. Klien sederhana sering cukup untuk melihat apakah halaman merespons. Menguji formulir checkout memerlukan pemuatan semua yang dibutuhkan formulir agar bekerja. Menonaktifkan berkas yang diperlukan mengurangi permintaan, tetapi pengujian tidak lagi menunjukkan pengalaman pengguna.

Pengaruh kesalahan dan percobaan ulang terhadap penggunaan

Permintaan yang dikirim tidak selalu mengembalikan data yang Anda butuhkan. Situs mungkin mengembalikan kesalahan, tantangan akses, atau halaman berbeda. Bahkan HTTP 200 tidak menjamin aplikasi menerima yang diinginkan: status melaporkan keberhasilan pada tingkat HTTP, sedangkan isi respons perlu diperiksa terpisah.

Aturan penagihan untuk permintaan ini berbeda-beda. Sebagian layanan menghitung permintaan yang dikirim. Layanan lain hanya menagih respons yang memenuhi definisi penyelesaian berhasilnya. API terkelola mungkin memasukkan beberapa percobaan internal pengambilan data dalam harga satu respons. Mode atau fitur tambahan terkadang mengubah aturan penagihan. Karena itu, “bayar per permintaan” tidak otomatis berarti “bayar hanya untuk data yang diperoleh”.

Percobaan ulang aplikasi berbeda dari percobaan ulang di dalam layanan. Ketika aplikasi mengirim permintaan lagi, aplikasi membuat permintaan baru. Ketika layanan mengulangi pekerjaan yang sudah Anda kirim, percobaan tersebut mungkin tercakup dalam harganya. Cari tahu percobaan mana yang dipotong dari paket Anda.

Selama pengujian, catat tiga angka: tugas yang dimulai, permintaan yang ditagih, dan tugas yang selesai. Penyelesaian bergantung pada tujuan. Untuk pengumpulan data, respons harus memuat bidang yang dibutuhkan dan informasi yang cukup baru. Untuk pemantauan ketersediaan, mendeteksi situs yang tidak tersedia dengan benar juga merupakan pemeriksaan yang selesai.

Angka-angka ini membantu menunjukkan biaya pekerjaan sebenarnya. Permintaan murah mungkin tidak sepadan jika respons terus memerlukan percobaan lain atau harus dibuang. Layanan lebih mahal mungkin melakukan sebagian pekerjaan untuk Anda. Bandingkan pengeluaran untuk memperoleh hasil yang dibutuhkan, termasuk pekerjaan yang tersisa bagi aplikasi.

Cara menghitung paket yang dibutuhkan

Pertama, hitung pekerjaan terencana: jumlah sasaran yang perlu diproses dan frekuensinya. Kemudian tambahkan permintaan di luar pengambilan normal, seperti percobaan ulang yang diamati saat pengujian. Hitung kelompok halaman berbeda secara terpisah jika perilakunya berbeda. Pisahkan pula cadangan untuk pertumbuhan beban kerja agar permintaan tambahan yang sama tidak ditambahkan dua kali.

Ambil contoh ilustrasi. Aplikasi memeriksa 150 URL setiap 30 menit selama 30 hari. Anggap pemeriksaan normal menggunakan satu permintaan menurut tarif yang dipilih, dan percobaan tambahan meningkatkan penggunaan sebesar 5%. Seluruh angka dan harga pada contoh ini bersifat hipotetis; bukan hasil pengujian penyedia atau tarif ProxyCompass.

Paket yang dipilih menyisakan cadangan 23,200 permintaan. Cadangan dapat menampung pertumbuhan beban kerja selama paket masih berlaku. Perkiraan percobaan ulang sudah termasuk dalam 10,800 percobaan tambahan; cadangan ini tidak boleh dihitung lagi sebagai penggunaan untuk percobaan ulang yang sama.

Anggap paket berharga $10. Paket memuat 250 ribu permintaan, sehingga harga nominal per seribu adalah $0.04. Anda membayar $10 untuk seluruh paket. Mengalikan perkiraan penggunaan 226,800 permintaan dengan tarif itu menghasilkan $9.072. Itu nilai bagian yang terpakai, bukan jumlah pembelian: harga paket tetap tersebut masih $10.

Sekarang anggap setelah percobaan tambahan, aplikasi menyelesaikan seluruh 216,000 pemeriksaan terjadwal. Seribu pemeriksaan selesai berbiaya sekitar $0.0463: $10 ÷ 216,000 × 1,000. Jumlah ini memperhitungkan permintaan tambahan dan cadangan yang dibeli. Jika lebih sedikit pemeriksaan selesai, bagi pengeluaran dengan jumlah sebenarnya.

Perhitungan dilakukan dengan cara yang sama untuk tugas lain. Pada penagihan penggunaan, kalikan permintaan yang ditagih dengan tarif, dengan memperhitungkan jumlah permintaan yang dicakup tarif tersebut. Pada paket, gunakan seluruh harga pembeliannya. Kemudian bagi pengeluaran dengan jumlah tugas selesai. Jika beberapa proyek berbagi paket, tentukan cara membagi biayanya di antara proyek tersebut.

Periksa juga apakah aplikasi dapat menyelesaikan pekerjaan tepat waktu. Contoh kami memerlukan 7,200 pemeriksaan per hari, dengan rata-rata lima pemeriksaan dimulai per menit. Anda dapat memulai seluruh 150 pemeriksaan sekaligus setiap setengah jam atau menyebarkannya sepanjang interval. Penggunaan paket tetap sama jika setiap pemeriksaan memerlukan jumlah percobaan sesuai asumsi, tetapi beban saat dimulai berbeda. Batas koneksi atau batas laju permintaan mungkin mencegah jadwal pertama berjalan sesuai rencana.

Cara mengurangi permintaan yang tidak diperlukan

Hapus alamat duplikat dan simpan hasil selama pekerjaan berlangsung. Setelah kegagalan, aplikasi seharusnya melanjutkan dari titik berhenti. Jika setiap kali memulai ulang seluruh daftar, halaman yang sudah diproses menggunakan paket lagi. Simpan catatan tugas yang selesai dan yang masih perlu diproses.

Gunakan metode pemuatan yang diperlukan untuk mengambil data. Jika teks yang dibutuhkan sudah ada dalam respons server, menjalankan browser mungkin tidak diperlukan. Jika data hanya muncul setelah skrip dieksekusi, unduhan sederhana mungkin tidak cukup. Pada layanan pengumpulan data, mode browser dan fitur tambahan terkadang menggunakan lebih banyak kredit atau memiliki tarif lain. Karena itu, satu kredit tidak selalu sama dengan satu permintaan.

Mengurangi ukuran respons tidak selalu menghemat permintaan. Jika penyedia menghitung panggilan HTTP, respons singkat dapat menggunakan jumlah permintaan sama dengan respons panjang. Untuk mengurangi hitungan, Anda dapat lebih jarang memeriksa data yang tidak berubah, memakai ulang hasil tersimpan, atau mengambil beberapa rekaman dalam satu panggilan API. Informasi tetap harus cukup baru untuk tugas Anda.

Batasi percobaan ulang dan pertimbangkan alasan kegagalan permintaan. Jika situs tidak tersedia sementara atau meminta Anda memperlambat, percobaan ulang langsung mungkin mengembalikan respons sama dan menghabiskan permintaan lain. Berhenti sejenak atau mengurangi frekuensi mungkin lebih berguna. Berhati-hatilah terutama pada tindakan yang membuat atau mengubah data: periksa hasil percobaan pertama sebelum mengirim lagi. Respons yang hilang tidak berarti server tidak melakukan apa-apa.

Setelah perubahan, periksa hasil maupun penggunaan. Jumlah permintaan mungkin turun karena aplikasi berhenti melakukan sebagian pekerjaan. Pengurangan berguna ketika Anda tetap memperoleh data yang diperlukan, dengan kelengkapan dan ketepatan waktu sama, menggunakan lebih sedikit permintaan.

Yang perlu diperiksa saat memilih tarif

Pertama, pastikan layanan bekerja untuk situs dan aplikasi Anda. Jenis proksi, negara yang tersedia, perilaku sesi, dan akses ke halaman yang diperlukan melalui IP yang diberikan semuanya penting. Kemudian bandingkan pekerjaan yang disertakan: siapa yang memuat halaman, menjalankan browser, mengekstrak data, dan mengulangi percobaan gagal? Ini membantu menjelaskan perbedaan harga per permintaan dua layanan.

Periksa masa berlaku paket, aturan isi ulang, dan perlakuan permintaan yang tidak terpakai. Paket besar dengan harga permintaan lebih rendah sepadan jika dapat digunakan tepat waktu untuk pekerjaan yang dibutuhkan. Jika sebagian permintaan yang dibeli tidak terpakai, biaya per tugas selesai mungkin lebih tinggi daripada dengan paket kecil.

Untuk perbandingan, pilih halaman khas proyek Anda, termasuk yang biasanya menimbulkan kesulitan. Catat waktu yang digunakan, permintaan terpakai, hasil yang diperoleh, dan pengaturan aplikasi. Pengujian ini akan menunjukkan ukuran paket yang dibutuhkan, perkiraan biaya pekerjaan, dan apakah Anda dapat menyelesaikannya tepat waktu.