Saat melakukan parsing di marketplace, otomatisasi media sosial, atau pengumpulan data melalui API, sangat penting untuk memilih strategi pengiriman permintaan dengan benar. Pengaturan yang salah dapat menyebabkan pemblokiran IP, CAPTCHA, dan pemborosan waktu. Dalam panduan ini, kita akan membahas kapan menggunakan permintaan paralel untuk kecepatan maksimal, dan kapan menggunakan permintaan berurutan untuk keamanan.
Perbedaan antara permintaan paralel dan berurutan
Permintaan berurutan adalah ketika skrip atau program Anda mengirimkan permintaan satu per satu: menunggu jawaban dari permintaan pertama, baru kemudian mengirimkan yang kedua. Ini lambat, tetapi aman dan terlihat sangat alami untuk situs target.
Permintaan paralel adalah ketika beberapa permintaan (5, 10, 50, atau bahkan ratusan) dikirim secara bersamaan, tanpa menunggu jawaban dari yang sebelumnya. Ini jauh lebih cepat, tetapi memberikan beban pada server dan dapat menimbulkan kecurigaan dari sistem anti-fraud.
Bayangkan melakukan parsing harga dari 10.000 produk di Wildberries. Secara berurutan dengan penundaan 2 detik antara permintaan ā itu 20.000 detik atau 5,5 jam. Jika Anda menjalankan 20 aliran paralel ā hanya 16 menit. Perbedaannya jelas, tetapi ada nuansa.
Penting: Permintaan paralel tidak berarti "kirim 1000 permintaan sekaligus". Ini adalah paralel yang terkontrol ā misalnya, 10-50 aliran aktif, masing-masing dengan penundaan. Tanpa kontrol, Anda akan segera mendapatkan larangan.
Perbandingan metode
| Parameter | Berurutan | Paralel |
|---|---|---|
| Kecepatan | Lambat (1 permintaan pada satu waktu) | Cepat (10-100+ sekaligus) |
| Risiko pemblokiran | Rendah | Sedang-tinggi |
| Beban pada proxy | Minimal | Tinggi |
| Kompleksitas pengaturan | Sederhana | Memerlukan pengalaman |
| Konsumsi memori | Rendah | Tinggi |
| Penanganan kesalahan | Lebih mudah dilacak | Lebih sulit untuk mencatat |
Kapan menggunakan permintaan paralel
Permintaan paralel adalah pilihan ketika kecepatan sangat penting dan volume data besar. Tetapi penting untuk memahami: ini hanya berfungsi dengan pengaturan proxy yang benar dan kontrol beban.
Skenario ideal untuk permintaan paralel
1. Parsing marketplace dengan katalog besar
Jika Anda perlu mengumpulkan harga dari 50.000 produk di Wildberries atau Ozon, parsing berurutan akan memakan waktu berhari-hari. Dengan 20-30 aliran paralel dan proxy data center, tugas ini dapat diselesaikan dalam beberapa jam.
Pengaturan: 20-30 aliran, masing-masing dengan IP terpisah, penundaan 1-3 detik antara permintaan dalam aliran. Rotasi IP setiap 100-200 permintaan.
2. Pengumpulan data dari API publik
Banyak API (misalnya, layanan cuaca, basis data perusahaan, layanan geolokasi) memiliki batasan pada permintaan dari satu IP: 100-1000 per hari. Permintaan paralel melalui kumpulan proxy memungkinkan Anda untuk menghindari batasan ini.
Contoh: Anda perlu mengumpulkan data tentang 10.000 perusahaan melalui API. Batasnya ā 500 permintaan/hari dari IP. Menggunakan 20 proxy secara paralel = 10.000 permintaan dalam sehari alih-alih 20 hari.
3. Memeriksa ketersediaan sumber daya
Jika Anda memeriksa ketersediaan situs, kerja cermin, atau memantau status server ā permintaan paralel menghemat jam. Di sini tidak perlu meniru perilaku manusia, hanya kecepatan yang penting.
4. Pemeriksaan massal proxy
Saat membeli kumpulan besar proxy (1000+ IP), Anda perlu cepat memeriksa fungsionalitas, kecepatan, dan geolokasi mereka. Pemeriksaan berurutan akan memakan waktu berjam-jam, sedangkan paralel hanya beberapa menit.
Perhatian: Permintaan paralel TIDAK cocok untuk bekerja dengan platform yang dilindungi (Facebook Ads, Instagram API, Google Ads), di mana penting untuk meniru perilaku pengguna nyata. Di sana, gunakan permintaan berurutan.
Persyaratan kunci untuk permintaan paralel
- Kumpulan proxy besar (minimal 10-20 IP, lebih baik 50-100+)
- Rotasi IP otomatis saat terjadi kesalahan
- Kontrol jumlah aliran simultan (tidak lebih dari 50-100)
- Penundaan antara permintaan bahkan di dalam aliran (0.5-2 detik)
- Pencatatan kesalahan untuk analisis penyebab pemblokiran
- Sistem retry (coba lagi) saat terjadi timeout
Kapan menggunakan permintaan berurutan
Permintaan berurutan adalah pilihan keamanan dan keandalan di atas kecepatan. Mereka meniru perilaku pengguna nyata dan meminimalkan risiko pemblokiran di platform yang dilindungi.
Skenario wajib untuk permintaan berurutan
1. Bekerja dengan akun iklan
Facebook Ads, TikTok Ads, Google Ads tidak hanya melacak IP, tetapi juga pola perilaku. Permintaan paralel dari satu akun akan segera menimbulkan kecurigaan. Satu akun = satu aliran = tindakan berurutan dengan penundaan 5-15 detik.
Contoh: Anda mengelola 20 akun iklan Facebook melalui browser anti-detect Dolphin Anty. Setiap akun bekerja di profil terpisah dengan proxy seluler, tindakan dilakukan secara berurutan: masuk ā memeriksa statistik ā menyesuaikan tawaran ā keluar. Penundaan 7-12 detik antara tindakan.
2. Otomatisasi tindakan di media sosial
Instagram, TikTok, VK memiliki batasan ketat pada tindakan: suka, mengikuti, komentar. Melebihi batas atau tindakan terlalu cepat = shadowban atau pemblokiran total. Hanya permintaan berurutan dengan penundaan acak 20-60 detik.
Pengaturan untuk Instagram: Satu akun melakukan maksimum 60 suka/jam. Itu 1 suka per menit dengan penundaan 45-75 detik (pengacakan penting!). Gunakan proxy terpisah untuk setiap akun.
3. Otorisasi dan bekerja dengan akun pribadi
Setiap tindakan yang memerlukan masuk ke akun (layanan email, bank, marketplace sebagai penjual) harus dilakukan secara berurutan. Upaya masuk paralel dari IP yang berbeda ke satu akun adalah jalan langsung menuju pemblokiran.
4. Situs dengan perlindungan anti-bot yang ketat
Platform dengan Cloudflare, Akamai, PerimeterX tidak hanya menganalisis frekuensi permintaan, tetapi juga pola mereka. Jika dari satu IP atau User-Agent datang 10 permintaan sekaligus ā itu adalah tanda jelas bot. Permintaan berurutan dengan penundaan 3-10 detik terlihat alami.
5. Volume data kecil
Jika Anda perlu mem-parsing 50-100 halaman, perbedaan waktu antara parsing berurutan dan paralel tidak signifikan (5 menit dibandingkan 1 menit). Namun, metode berurutan menjamin tidak ada masalah.
Penundaan yang benar untuk permintaan berurutan
| Platform/tugas | Penundaan antara permintaan | Pengacakan |
|---|---|---|
| Facebook Ads (tindakan di akun) | 7-15 detik | Ā±30% |
| Instagram (suka, mengikuti) | 45-90 detik | Ā±40% |
| TikTok (tampilan, suka) | 30-60 detik | Ā±35% |
| Google Ads (permintaan API) | 5-10 detik | Ā±25% |
| Parsing dengan Cloudflare | 3-7 detik | Ā±30% |
| Situs biasa tanpa perlindungan | 1-3 detik | Ā±20% |
Tip: Pengacakan penundaan sangat penting. Jika skrip Anda melakukan permintaan tepat setiap 5.00 detik ā itu adalah pola bot. Gunakan random dari 4 hingga 7 detik untuk meniru manusia.
Risiko pemblokiran dengan berbagai metode
Memahami risiko membantu memilih strategi yang tepat dan mengatur perlindungan. Pemblokiran terjadi tidak hanya karena frekuensi permintaan, tetapi juga karena pola mereka.
Apa yang dilacak oleh sistem anti-fraud
1. Frekuensi permintaan dari satu IP
Jika dari satu IP datang 100 permintaan per menit ā ini jelas bot. Batasan bervariasi: situs biasa mentolerir 10-30 permintaan/menit, platform yang dilindungi ā 2-5 permintaan/menit.
Solusi untuk permintaan paralel: Sebarkan permintaan di antara kumpulan IP yang besar. Misalnya, 1000 permintaan/menit = 50 IP masing-masing 20 permintaan. Ini terlihat seperti 50 pengguna biasa.
2. Interval yang sama antara permintaan
Permintaan tepat setiap 2.00 detik ā tanda otomatisasi. Manusia mengklik dengan interval yang berbeda: 1.8 detik, 3.2 detik, 2.1 detik.
Solusi: Tambahkan pengacakan Ā±30-50% dari penundaan dasar. Alih-alih 5 detik tetap, gunakan random(3.5, 7.5).
3. Tidak adanya perilaku pengguna yang khas
Pengguna nyata tidak langsung pergi ke halaman produk ā mereka terlebih dahulu mengunjungi halaman utama, mencari kategori, mengklik produk. Bot langsung meminta URL tertentu.
Solusi untuk platform kritis: Meniru jalur lengkap pengguna. Sebelum parsing produk, lakukan 2-3 permintaan: beranda ā kategori ā produk. Ini memperlambat pekerjaan, tetapi mengurangi risiko pemblokiran hingga 70-80%.
4. User-Agent dan header yang mencurigakan
User-Agent yang usang (misalnya, Chrome 95 di tahun 2024), tidak adanya header Accept-Language, Referer ā tanda bot.
Solusi: Gunakan User-Agent yang terkini (Chrome 120+, Firefox 120+), tambahkan kumpulan header lengkap seperti di browser nyata. Rotasi User-Agent bersama dengan IP.
Perbandingan risiko pemblokiran
| Skenario | Risiko pada berurutan | Risiko pada paralel |
|---|---|---|
| Parsing marketplace (10K permintaan) | Rendah (5-10%) | Sedang (20-30%) |
| Bekerja dengan Facebook Ads | Rendah (2-5%) | Kritis (80-95%) |
| Otomatisasi Instagram | Sedang (15-25%) | Tinggi (60-80%) |
| API publik (dalam batas) | Sangat rendah (1-3%) | Rendah (5-10%) |
| Situs dengan Cloudflare | Sedang (10-20%) | Tinggi (40-60%) |
Proxy mana yang cocok untuk setiap metode
Jenis proxy secara langsung mempengaruhi kemungkinan penggunaan permintaan paralel atau berurutan. Pemilihan yang salah akan mengakibatkan pemblokiran atau biaya berlebih.
Proxy untuk permintaan paralel
Proxy data center adalah pilihan optimal untuk parsing massal dan permintaan paralel. Mereka murah (dari $1-3 per IP/bulan), cepat (ping 20-50 ms) dan tersedia dalam jumlah besar. Kekurangannya ā mudah dikenali sebagai proxy, sehingga tidak cocok untuk platform yang dilindungi.
Kapan digunakan: Parsing marketplace, pengumpulan data dari sumber publik, memeriksa ketersediaan sumber daya, permintaan API massal ke layanan tanpa perlindungan ketat.
Pengaturan: Beli kumpulan 50-100 IP, atur 20-30 aliran paralel, setiap aliran menggunakan IP-nya sendiri. Rotasi setiap 100-200 permintaan atau saat terjadi kesalahan.
Proxy residensial ā lebih mahal (dari $3-7 per 1 GB trafik), tetapi terlihat seperti pengguna nyata. Cocok untuk permintaan paralel ke platform yang dilindungi, jika diperlukan kecepatan, tetapi dengan hati-hati.
Kapan digunakan: Parsing media sosial (tanpa otorisasi), pengumpulan data dari situs dengan Cloudflare, bekerja dengan platform yang memblokir data center. Untuk permintaan paralel, diperlukan kumpulan IP besar dengan rotasi otomatis.
Penting: Saat menggunakan permintaan paralel melalui proxy residensial, kontrol penggunaan trafik. 10.000 permintaan dapat "menghabiskan" 5-10 GB, yang akan menelan biaya $20-50. Data center lebih murah: trafik tanpa batas seharga $100-200/bulan untuk 100 IP.
Proxy untuk permintaan berurutan
Proxy seluler adalah jenis yang paling andal untuk bekerja dengan platform yang dilindungi. IP terlihat seperti perangkat seluler nyata (operator 4G/5G), yang meminimalkan risiko pemblokiran. Kekurangannya ā mahal (dari $50-150 per IP/bulan).
Kapan digunakan: Facebook Ads, Instagram, TikTok, Google Ads ā semua yang memerlukan keamanan maksimal dan meniru pengguna nyata. Satu akun = satu proxy seluler = tindakan berurutan.
Pengaturan: Setiap akun iklan atau media sosial terikat pada IP seluler terpisah. Tindakan dilakukan secara berurutan dengan penundaan 10-60 detik. IP tidak dirotasi (satu akun selalu bekerja dengan satu IP).
Proxy residensial ā alternatif yang baik untuk proxy seluler jika anggaran terbatas. Cocok untuk tugas yang kurang kritis: parsing dengan otorisasi, otomatisasi SMM, bekerja dengan marketplace sebagai penjual.
Kapan digunakan: Mengelola akun marketplace (Wildberries, Ozon sebagai penjual), otomatisasi posting di media sosial (tidak massal), parsing data yang memerlukan otorisasi.
Rekomendasi pemilihan proxy
| Tugas | Jenis proxy | Metode permintaan | Jumlah IP |
|---|---|---|---|
| Parsing marketplace (volume besar) | Data center | Paralel | 50-100+ |
| Facebook Ads (multi-accounting) | Seluler | Berurutan | 1 IP per akun |
| Otomatisasi Instagram | Seluler/residensial | Berurutan | 1 IP per akun |
| Parsing dengan Cloudflare | Residensial | Paralel (hati-hati) | 20-50 |
| API publik (pengumpulan massal) | Data center | Paralel | 10-30 |
| Marketplace (akun penjual pribadi) | Residensial | Berurutan | 1 IP per akun |
Pengaturan optimal: penundaan, aliran, waktu tunggu
Pengaturan parameter yang benar sangat penting untuk keseimbangan antara kecepatan dan keamanan. Pengaturan yang terlalu agresif akan menyebabkan pemblokiran, sementara yang terlalu hati-hati akan membuang waktu.
Pengaturan permintaan paralel
Jumlah aliran simultan (concurrency)
Ini adalah parameter kunci. Terlalu banyak aliran = beban berlebih pada proxy dan server target. Terlalu sedikit = kecepatan rendah.
Rekomendasi:
- Parsing marketplace: 20-50 aliran dengan kumpulan 50+ proxy
- API publik: 10-30 aliran, sesuaikan dengan batasan API
- Situs dengan perlindungan: 5-15 aliran, lebih banyak = risiko pemblokiran
- Pemeriksaan proxy: 50-100 aliran (di sini kecepatan lebih penting)
Penundaan dalam aliran
Bahkan saat bekerja secara paralel, setiap aliran harus melakukan jeda antara permintaannya. Ini mengurangi beban pada satu IP dan mengurangi risiko pemblokiran.
Rekomendasi:
- Situs sederhana: 0.5-2 detik antara permintaan dalam satu aliran
- Marketplace: 1-3 detik dengan pengacakan Ā±30%
- Situs dengan Cloudflare: 2-5 detik dengan pengacakan Ā±40%
- API dengan batasan: hitung berdasarkan batas (misalnya, 100 permintaan/menit = 0.6 detik/permintaan, buat 1 detik untuk cadangan)
Waktu tunggu (timeout)
Waktu menunggu jawaban dari server. Waktu tunggu yang terlalu pendek = kehilangan data karena jawaban yang lambat. Terlalu panjang = aliran terjebak.
Rekomendasi:
- Situs cepat: 10-15 detik
- Situs/API lambat: 20-30 detik
- Melalui proxy residensial: +5-10 detik (mereka lebih lambat daripada data center)
- Connection timeout: 5-10 detik (waktu untuk membangun koneksi)
Retry (coba lagi)
Saat terjadi kesalahan (timeout, 503, pemblokiran proxy), perlu mengulangi permintaan dengan IP yang berbeda. Tanpa retry, Anda akan kehilangan sebagian data.
Pengaturan: 2-3 percobaan per permintaan, ganti proxy setelah setiap percobaan yang gagal, jeda 3-5 detik sebelum retry.
Pengaturan permintaan berurutan
Penundaan dasar antara permintaan
Tergantung pada platform dan jenis tindakan. Aturan utama: meniru pengguna nyata.
Rekomendasi berdasarkan platform:
- Facebook Ads (perpindahan antara bagian akun): 7-15 detik
- Instagram (suka): 45-90 detik, maksimum 60 suka/jam
- Instagram (mengikuti): 60-120 detik, maksimum 30 mengikuti/jam
- TikTok (tampilan): 30-60 detik
- Parsing dengan otorisasi: 3-7 detik
- Marketplace (tindakan di akun penjual): 5-10 detik
Pengacakan
Wajib untuk semua permintaan berurutan. Gunakan deviasi Ā±30-50% dari penundaan dasar.
Contoh: Penundaan dasar 10 detik, pengacakan Ā±40% ā penundaan aktual akan menjadi 6-14 detik (nilai acak setiap kali).
Waktu tunggu
Untuk permintaan berurutan, Anda dapat menggunakan waktu tunggu yang lebih lama, karena tidak ada risiko pemblokiran semua aliran.
Rekomendasi: 30-60 detik untuk platform yang dilindungi (Facebook, Instagram), 15-30 detik untuk situs biasa.
Tip praktis: Mulailah dengan pengaturan konservatif (lebih sedikit aliran, lebih banyak penundaan), secara bertahap tingkatkan agresivitas, sambil memantau persentase kesalahan. Jika kesalahan >5-10% ā kembali ke langkah sebelumnya.
Alat untuk menerapkan kedua metode
Pemilihan alat tergantung pada tugas Anda dan keterampilan teknis. Untuk tugas bisnis (arbitrase, SMM, e-commerce) gunakan solusi siap pakai tanpa kode. Untuk tugas teknis ā pustaka dan kerangka kerja.
Solusi siap pakai tanpa kode (untuk bisnis)
Browser anti-detect untuk multi-accounting
Jika Anda bekerja dengan akun iklan atau media sosial, browser anti-detect adalah standar industri. Mereka secara otomatis mengelola proxy, jejak browser, dan mengisolasi akun.
Solusi populer:
- Dolphin Anty: pemimpin untuk arbitrase Facebook/TikTok, tarif gratis untuk 10 profil, pengaturan proxy yang sederhana
- AdsPower: baik untuk e-commerce (Amazon, eBay), ada otomatisasi melalui RPA (tanpa kode)
- Multilogin: yang termahal ($100+/bulan), tetapi perlindungan maksimal untuk arbitrase serius
- GoLogin: alternatif anggaran ($25/bulan), cocok untuk SMM dan tim kecil
Bagaimana mereka bekerja dengan proxy: Buat profil browser ā hubungkan proxy ā semua tindakan dalam profil ini dilakukan melalui IP ini. Satu profil = satu akun = tindakan berurutan. Untuk bekerja secara paralel, buka beberapa profil sekaligus (setiap dengan proxy-nya sendiri).
Parser dan scraper (siap pakai)
Untuk mengumpulkan data dari marketplace dan situs, ada alat siap pakai dengan GUI yang tidak memerlukan pemrograman.
- Octoparse: pembangun parser visual, dukungan proxy, dapat mengatur aliran paralel melalui antarmuka
- ParseHub: analog Octoparse, tarif gratis untuk 200 halaman, pengaturan penundaan melalui GUI
- Scrapy Cloud: layanan cloud untuk menjalankan spider Scrapy (memerlukan pengetahuan Python minimal)
Otomatisasi SMM (tanpa kode)
Untuk mengelola media sosial, ada layanan dengan otomatisasi melalui antarmuka.
- Jarvee: otomatisasi Instagram, TikTok, Twitter, dukungan proxy bawaan, pengaturan penundaan melalui GUI (hati-hati: otomatisasi agresif menyebabkan pemblokiran)
- Ingramer (Inflact): otomatisasi Instagram yang aman, bekerja melalui proxy mereka
- Combin: langganan/like yang ditargetkan di Instagram, dukungan proxy eksternal
Alat teknis (untuk pengembang)
Jika Anda menulis skrip Anda sendiri untuk parsing atau otomatisasi, gunakan pustaka yang teruji.
Python (yang paling populer untuk parsing):
- Requests + threading/asyncio: untuk permintaan paralel sederhana, mudah mengatur proxy
- aiohttp: pustaka asinkron untuk permintaan sangat paralel (1000+ sekaligus)
- Scrapy: kerangka kerja untuk parsing, dukungan bawaan untuk rotasi proxy, middleware untuk penundaan
- Selenium: untuk situs dengan JavaScript, lebih lambat, tetapi menghindari banyak perlindungan
- Playwright: alternatif modern untuk Selenium, lebih cepat dan lebih nyaman
JavaScript/Node.js:
- Axios: pustaka populer untuk permintaan HTTP, pengaturan proxy yang sederhana
- Puppeteer: pustaka untuk mengontrol Chrome, sangat baik untuk scraping situs yang dinamis
- Cheerio: pustaka untuk memanipulasi HTML, sangat cepat dan efisien
Kesimpulan:
Memilih metode yang tepat untuk pengiriman permintaan sangat penting untuk mencapai hasil yang diinginkan, baik dalam hal kecepatan maupun keamanan. Dengan memahami perbedaan antara permintaan paralel dan berurutan, serta memilih proxy yang sesuai, Anda dapat memaksimalkan efisiensi pengumpulan data Anda.