Prezzi dei proxy per richiesta

Che cosa paghi

Paghi il numero di richieste conteggiate dal fornitore. Può vendere pacchetti fissi oppure addebitare il consumo del servizio. I prezzi vengono spesso indicati per mille o per un milione di richieste. Questo facilita il confronto delle tariffe, ma non indica quanto devi spendere al momento dell’acquisto: il pacchetto più piccolo può contenere più richieste.

La stessa parola, «richiesta», può descrivere servizi diversi. Un proxy ordinario inoltra ai siti le richieste della tua applicazione e ne restituisce le risposte. La tua applicazione carica le pagine ed estrae i dati. Con un’API di raccolta dati, il prezzo può includere anche l’esecuzione di un browser, la gestione delle restrizioni di accesso e la preparazione dei risultati. Confrontare soltanto il prezzo delle richieste non basta quindi; devi sapere che cosa fa il servizio per quel prezzo.

Questa tariffazione è comoda per lavori che seguono una programmazione. Potresti già sapere quante pagine verificare e con quale frequenza. Accerta poi quante richieste utilizza ogni verifica. Puoi così stimare il pacchetto necessario per un mese e quanto crescerà l’utilizzo aggiungendo altre pagine.

Le dimensioni della risposta non influenzano necessariamente il prezzo. Se la tariffa addebita lo stesso importo per ogni richiesta, recuperare più dati in una risposta può costare quanto recuperarne una piccola. Verifica però che cosa include la tariffa: possono esserci limiti di banda, dimensione della risposta o tempo di esecuzione. Anche l’elaborazione aggiuntiva dei dati può avere un costo separato.

Un pacchetto di richieste non determina quanti indirizzi IP ricevi. Un servizio a rotazione, per esempio, può fornire accesso a un pool di IP attraverso un endpoint di connessione condiviso. I cambi di IP e il mantenimento di un indirizzo per una sessione dipendono dalle impostazioni del servizio. Un cambio di IP da solo non indica quante richieste verranno addebitate.

Che cosa conteggia il servizio come una richiesta

Inizia distinguendo una richiesta da una connessione. Una richiesta HTTP chiede a un sito di fare qualcosa, come restituire una pagina o fornire dati. Il sito invia una risposta. Il trasferimento di dati in entrambe le direzioni non significa, di per sé, che vadano sottratte due richieste. Questo richiederebbe una regola di fatturazione separata.

Una connessione è il canale attraverso il quale l’applicazione comunica con il server. Più richieste possono utilizzare la stessa connessione. HTTP/1.1 consente di riutilizzare una connessione, mentre HTTP/2 permette di eseguire più scambi contemporaneamente su di essa. Il numero di richieste, le connessioni aperte e le connessioni attive nello stesso momento sono quindi misure diverse.

HTTPS aggiunge un altro dettaglio. Quando si collega attraverso un proxy HTTP, l’applicazione invia comunemente un comando CONNECT per creare un tunnel verso il sito. Le richieste successive viaggiano all’interno del tunnel in forma cifrata. Il proxy inoltra i dati ma, nell’uso ordinario, non può leggere le singole richieste HTTP. Anche un proxy SOCKS fornisce una connessione alla destinazione; ogni azione dell’applicazione non necessita necessariamente di una nuova connessione.

Per questo alcuni servizi utilizzano «richiesta» per indicare una connessione o un altro evento conteggiabile dal loro server proxy. Altri conteggiano singole richieste HTTP oppure chiamate a un’API. Il numero di richieste negli strumenti per sviluppatori del browser può quindi differire dall’utilizzo nel pannello del fornitore. Il solo supporto di HTTP, HTTPS o SOCKS5 non stabilisce la regola di conteggio.

Prima di acquistare un pacchetto grande, esegui una piccola prova. Registra quante attività completa l’applicazione e quante richieste sottrae il servizio. Utilizza la stessa applicazione, protocollo e impostazioni previsti per il lavoro successivo. Una prova con un client HTTP semplice non mostra l’utilizzo di un browser che carica anche script e altre risorse delle pagine.

Perché una pagina può utilizzare più richieste

Aprire una pagina richiede spesso più del documento principale. Il browser carica separatamente stili, script, immagini e dati. Una pagina aperta può continuare a contattare il server per aggiornamenti. Anche alcune di queste richieste attraversano il proxy, secondo le impostazioni dell’applicazione. Il modo in cui vengono addebitate dipende dalla tariffa.

Seguire un reindirizzamento aggiunge una richiesta. Se il sito risponde che una pagina si trova a un altro indirizzo, un’applicazione configurata per seguire il reindirizzamento invia un’altra richiesta HTTP a quell’indirizzo. Recuperare un documento con un client semplice e aprire la pagina completa nel browser può quindi utilizzare un numero diverso di richieste. Il numero di URL nel tuo elenco non indica ancora quante richieste serviranno per elaborarli.

Un’API può funzionare nel senso opposto: una richiesta può recuperare molti dati. In questo esempio un browser effettua cinque richieste per caricare una pagina di cuffie con il relativo prezzo. Un’applicazione utilizza lo stesso proxy per chiamare l’API di catalogo del rivenditore e recupera cinque prezzi di prodotti in una richiesta. È l’API del rivenditore, che fornisce dati sui prodotti. Se restituisce il catalogo in pagine, ogni pagina necessita di un’altra richiesta. A volte puoi aumentare il numero di prodotti per risposta, purché l’API supporti l’impostazione e restituisca tutti i dati necessari.

Questo approccio aiuta a ottenere più lavoro utile da un pacchetto. Caricare ripetutamente pagine complete, recuperare dati già salvati e verificare i prezzi più spesso del necessario può consumare rapidamente la quota. Recuperare più prodotti per chiamata, salvare i risultati e scegliere una frequenza di controllo adatta riduce le richieste necessarie per lo stesso lavoro. A parità di carico, la quota può durare più a lungo entro la validità del pacchetto; in alternativa puoi utilizzarla per verificare più prodotti.

È utile misurare l’utilizzo per attività completata. Può significare verificare una pagina, recuperare un elenco completo oppure controllare un elemento che compare dopo l’esecuzione degli script. Misura l’intera sequenza necessaria per raggiungere quel risultato. Sono compresi i caricamenti aggiuntivi di pagine che è facile trascurare contando soltanto gli URL iniziali.

Dove è utile questo modello di prezzo

Monitoraggio programmato

L’utilizzo delle richieste può essere legato a verifiche regolari. Un’applicazione può monitorare la disponibilità delle pagine, le modifiche di elenchi pubblici oppure i risultati di ricerca per una regione richiesta. Conosci in anticipo il numero di obiettivi e la frequenza delle verifiche. Una prova mostra quante richieste utilizza ogni controllo e aiuta a stimare il consumo mensile.

Non tutte le pagine devono essere verificate con la stessa frequenza. Se le informazioni cambiano una volta al giorno, verificarle ogni minuto restituirà solitamente gli stessi dati. Controlli più frequenti possono essere riservati alle pagine in cui conta rilevare rapidamente un cambiamento. Questo mantiene il pacchetto disponibile per le osservazioni necessarie.

Raccolta di dati tramite API ed elenchi

Qui l’utilizzo dipende da come il sito fornisce le informazioni. Se l’elenco contiene già tutto ciò che serve, non c’è motivo di aprire ogni pagina di dettaglio. Le richieste aggiuntive possono essere riservate alle voci con dati mancanti oppure ai record cambiati dall’esecuzione precedente. Quanto più dati necessari recuperi in una chiamata, tante meno richieste servono per la raccolta completa.

Devi anche considerare che cosa fa il servizio. Un’API di ricerca può restituire risultati già elaborati, mentre un proxy ordinario lascia download ed elaborazione alla tua applicazione. Sono quantità di lavoro diverse. Nel confronto dei prezzi verifica che cosa contiene la risposta e che cosa devi ancora fare autonomamente.

Analisi dei siti e verifiche nel browser

Un’analisi tecnica ha spesso una sequenza chiara: aprire un indirizzo, verificare la risposta, seguire un reindirizzamento se necessario e salvare il risultato. Se la maggior parte degli indirizzi viene gestita in modo simile, una prova facilita la stima dell’utilizzo. Una verifica nel browser può richiedere più richieste perché dipende da script, immagini ed elementi funzionanti della pagina.

Scegli il metodo di verifica in base allo scopo. Un client semplice è spesso sufficiente per vedere se una pagina risponde. Provare un modulo di acquisto richiede il caricamento di ciò che serve al modulo per funzionare. Disattivare file necessari riduce le richieste, ma la prova non mostrerà più ciò che vive l’utente.

Come errori e nuovi tentativi influenzano l’utilizzo

Una richiesta inviata non restituisce sempre i dati necessari. Un sito può restituire un errore, una verifica di accesso oppure una pagina diversa. Nemmeno HTTP 200 garantisce che l’applicazione abbia ricevuto ciò che desiderava: lo stato indica il successo a livello HTTP, mentre il contenuto della risposta richiede una verifica separata.

Le regole di fatturazione di queste richieste variano. Alcuni servizi conteggiano le richieste inviate. Altri addebitano soltanto le risposte che soddisfano la loro definizione di completamento riuscito. Un’API gestita può includere nel prezzo di una risposta più tentativi interni per recuperare i dati. Modalità o funzioni aggiuntive a volte modificano le regole di fatturazione. «Pagamento per richiesta» non significa quindi automaticamente «pagamento soltanto per i dati recuperati».

Un nuovo tentativo della tua applicazione è diverso da un nuovo tentativo interno al servizio. Quando l’applicazione invia nuovamente la richiesta, ne crea una nuova. Quando il servizio riprova un lavoro già inviato, quei tentativi possono essere inclusi nel prezzo. Accerta quali tentativi vengono sottratti dal pacchetto.

Durante una prova registra tre numeri: attività avviate, richieste addebitate e attività completate. Il completamento dipende dallo scopo. Per la raccolta di dati, la risposta deve contenere i campi richiesti e informazioni abbastanza recenti. Per il monitoraggio della disponibilità, anche rilevare correttamente un sito indisponibile è una verifica completata.

Questi numeri aiutano a mostrare il costo reale del lavoro. Richieste economiche possono offrire poco valore se le risposte necessitano continuamente di un altro tentativo oppure devono essere scartate. Un servizio più costoso può svolgere parte del lavoro per te. Confronta la spesa necessaria per ottenere il risultato richiesto, compreso il lavoro lasciato all’applicazione.

Come calcolare il pacchetto necessario

Prima conta il lavoro previsto: quanti obiettivi devono essere elaborati e con quale frequenza. Aggiungi poi le richieste necessarie oltre al normale recupero, come i nuovi tentativi osservati durante la prova. Calcola separatamente i gruppi di pagine se si comportano diversamente. Mantieni separata anche una riserva per la crescita del carico, affinché le stesse richieste aggiuntive non vengano sommate due volte.

Considera un esempio illustrativo. Un’applicazione verifica 150 URL ogni 30 minuti per 30 giorni. Supponi che una verifica normale utilizzi una richiesta secondo la tariffa scelta e che i tentativi aggiuntivi aumentino l’utilizzo del 5%. Tutti i numeri e i prezzi di questo esempio sono ipotetici; non sono risultati di prove di un fornitore né una tariffa ProxyCompass.

Il pacchetto scelto lascia una riserva di 23 200 richieste. Può coprire la crescita del carico finché il pacchetto rimane valido. I nuovi tentativi previsti sono già inclusi nei 10 800 tentativi aggiuntivi; questa riserva non deve essere conteggiata nuovamente come utilizzo per gli stessi tentativi.

Supponi che il pacchetto costi 10 $. Contiene 250 mila richieste, quindi il prezzo nominale per mille è di 0,04 $. Paghi 10 $ per l’intero pacchetto. Moltiplicando l’utilizzo previsto di 226 800 richieste per quella tariffa si ottengono 9,072 $. È il valore della parte utilizzata, non l’importo dell’acquisto: il pacchetto fisso è comunque costato 10 $.

Supponi ora che, dopo i tentativi aggiuntivi, l’applicazione completi tutte le 216 000 verifiche programmate. Mille verifiche completate costano circa 0,0463 $: 10 $ ÷ 216 000 × 1 000. Questo importo considera sia le richieste aggiuntive sia la riserva acquistata. Se vengono completate meno verifiche, dividi la spesa per il loro numero effettivo.

Il calcolo funziona allo stesso modo per altre attività. Con la fatturazione a consumo, moltiplica le richieste fatturabili per la tariffa, tenendo conto di quante richieste copre. Con un pacchetto utilizza il suo intero prezzo di acquisto. Dividi poi la spesa per il numero di attività completate. Se più progetti condividono un pacchetto, decidi come ripartirne il costo.

Verifica anche se l’applicazione può completare il lavoro in tempo. Il nostro esempio richiede 7 200 verifiche al giorno, con una media di cinque avvii al minuto. Potresti avviare tutte le 150 verifiche insieme ogni mezz’ora oppure distribuirle nell’intervallo. L’utilizzo del pacchetto sarebbe identico se ogni verifica richiedesse il numero ipotizzato di tentativi, ma il carico all’avvio sarebbe diverso. Un limite di connessioni o di frequenza delle richieste può impedire l’esecuzione della prima programmazione come prevista.

Come ridurre le richieste non necessarie

Elimina gli indirizzi duplicati e salva i risultati mentre il lavoro prosegue. Dopo un errore, l’applicazione dovrebbe continuare dal punto in cui si è fermata. Se ricomincia ogni volta l’intero elenco, le pagine già elaborate consumano nuovamente il pacchetto. Conserva un registro delle attività completate e di quelle ancora da elaborare.

Utilizza il metodo di caricamento necessario per recuperare i dati. Se il testo richiesto è già nella risposta del server, eseguire un browser può essere inutile. Se i dati compaiono soltanto dopo l’esecuzione degli script, un semplice download potrebbe non bastare. Nei servizi di raccolta dati, la modalità browser e le funzioni aggiuntive a volte utilizzano più crediti oppure hanno un’altra tariffa. Un credito non equivale quindi sempre a una richiesta.

Ridurre le dimensioni della risposta non risparmia sempre richieste. Se il fornitore conteggia le chiamate HTTP, una risposta breve può utilizzare tante richieste quanto una lunga. Per ridurre il numero puoi controllare meno spesso i dati invariati, riutilizzare un risultato salvato oppure recuperare più dati in una chiamata API. Le informazioni devono comunque rimanere abbastanza recenti per la tua attività.

Limita i nuovi tentativi e considera perché la richiesta è fallita. Se un sito è temporaneamente indisponibile o ti chiede di rallentare, un tentativo immediato può restituire la stessa risposta e consumare un’altra richiesta. Una pausa o una riduzione della frequenza può essere più utile. Presta particolare attenzione alle azioni che creano o modificano dati: verifica il risultato del primo tentativo prima di inviare nuovamente. Una risposta persa non significa che il server non abbia fatto nulla.

Dopo le modifiche verifica i risultati oltre all’utilizzo. Il numero di richieste può essere diminuito perché l’applicazione ha smesso di svolgere parte del lavoro. Una riduzione è utile quando ottieni ancora i dati richiesti, con la stessa completezza e tempestività, utilizzando meno richieste.

Che cosa verificare quando scegli una tariffa

Prima assicurati che il servizio funzioni per i tuoi siti e la tua applicazione. Contano tipo di proxy, paesi disponibili, comportamento delle sessioni e accesso alle pagine richieste tramite gli IP forniti. Confronta poi il lavoro incluso: chi carica la pagina, esegue il browser, estrae i dati e ripete i tentativi falliti? Questo aiuta a spiegare perché due servizi addebitano prezzi diversi per richiesta.

Verifica la validità del pacchetto, le regole delle ricariche e il trattamento delle richieste inutilizzate. Un pacchetto grande con un prezzo per richiesta inferiore è conveniente se puoi utilizzarlo per lavoro necessario entro la scadenza. Se alcune richieste acquistate rimangono inutilizzate, il costo per attività completata può essere più alto rispetto a un pacchetto più piccolo.

Per un confronto, seleziona pagine tipiche del progetto, comprese quelle che causano solitamente difficoltà. Registra tempo impiegato, richieste utilizzate, risultati ottenuti e impostazioni dell’applicazione. Questa prova indicherà la dimensione del pacchetto necessaria, il costo approssimativo del lavoro e se puoi terminarlo in tempo.