Cobrança de proxies por solicitação

Pelo que você paga

Você paga pelo número de solicitações contabilizadas pelo provedor. Ele pode vender pacotes fixos ou cobrar conforme você usa o serviço. Os preços costumam ser informados por mil ou por milhão de solicitações. Isso facilita comparar tarifas, mas não informa quanto você precisa gastar na compra: o menor pacote pode conter mais solicitações.

A mesma palavra, “solicitação”, pode descrever serviços diferentes. Um proxy comum encaminha as solicitações da sua aplicação aos sites e devolve as respostas deles. Sua aplicação carrega as páginas e extrai os dados. Com uma API de coleta de dados, o preço também pode incluir executar um navegador, tratar restrições de acesso e preparar os resultados. Portanto, comparar apenas o preço da solicitação não basta; você precisa saber o que o serviço faz por aquele preço.

Essa cobrança é conveniente para trabalhos que seguem uma programação. Você talvez já saiba quantas páginas verificar e com que frequência. Depois, descubra quantas solicitações cada verificação usa. Assim, poderá estimar o pacote necessário para um mês e quanto o uso crescerá se adicionar mais páginas.

O tamanho da resposta não necessariamente afeta o preço. Se a tarifa cobrar o mesmo valor por cada solicitação, obter mais dados em uma resposta poderá custar o mesmo que obter uma resposta pequena. Porém, verifique o que a tarifa inclui: pode haver limites de largura de banda, tamanho da resposta ou tempo de execução. O processamento adicional de dados também pode ter uma cobrança separada.

Um pacote de solicitações não determina quantos endereços IP você recebe. Um serviço rotativo, por exemplo, pode oferecer acesso a um pool de IPs por um ponto de conexão compartilhado. As mudanças de IP e a manutenção de um endereço durante uma sessão dependem das configurações do serviço. Uma mudança de IP, isoladamente, não informa quantas solicitações serão cobradas.

O que o serviço contabiliza como uma solicitação

Comece separando uma solicitação de uma conexão. Uma solicitação HTTP pede a um site que faça algo, como retornar uma página ou fornecer dados. O site envia uma resposta. Os dados circularem nos dois sentidos não significa, por si só, que duas solicitações devam ser descontadas. Isso exigiria uma regra de cobrança separada.

Uma conexão é o canal pelo qual a aplicação se comunica com o servidor. Várias solicitações podem usar a mesma conexão. O HTTP/1.1 permite reutilizar uma conexão, enquanto o HTTP/2 permite executar várias trocas por ela ao mesmo tempo. Portanto, a contagem de solicitações, as conexões abertas e as conexões ativas ao mesmo tempo são medidas diferentes.

O HTTPS acrescenta outro detalhe. Ao se conectar por um proxy HTTP, a aplicação costuma enviar um comando CONNECT para criar um túnel até o site. As solicitações posteriores circulam dentro desse túnel de forma criptografada. O proxy encaminha os dados, mas, no uso comum, não consegue ler as solicitações HTTP individuais. Um proxy SOCKS também fornece uma conexão com o destino; cada ação da aplicação não precisa necessariamente de uma nova conexão.

Por esse motivo, alguns serviços usam “solicitação” para significar uma conexão ou outro evento que o servidor proxy consegue contabilizar. Outros contabilizam solicitações HTTP individuais ou chamadas a uma API. Por isso, a contagem de solicitações nas ferramentas de desenvolvedor de um navegador pode diferir do uso no painel do provedor. O suporte a HTTP, HTTPS ou SOCKS5, isoladamente, não determina a regra de contagem.

Antes de comprar um pacote grande, faça um teste pequeno. Registre quantas tarefas a aplicação conclui e quantas solicitações o serviço desconta. Use a mesma aplicação, o mesmo protocolo e as mesmas configurações que pretende usar depois. Um teste com um cliente HTTP simples não mostrará o uso de um navegador que também carrega scripts e outros recursos da página.

Por que uma página pode usar várias solicitações

Abrir uma página costuma exigir mais do que seu documento principal. O navegador carrega separadamente estilos, scripts, imagens e dados. Uma página aberta pode continuar contatando o servidor para obter atualizações. Algumas dessas solicitações também passam pelo proxy, dependendo das configurações da aplicação. A forma de cobrá-las depende da tarifa.

Seguir um redirecionamento acrescenta uma solicitação. Se o site responder que uma página está em outro endereço, uma aplicação configurada para seguir o redirecionamento enviará outra solicitação HTTP àquele endereço. Por isso, obter um documento com um cliente simples e abrir a página completa em um navegador pode usar números diferentes de solicitações. O número de URLs na sua lista ainda não informa quantas solicitações serão necessárias para processá-las.

Uma API pode funcionar no sentido contrário: uma solicitação pode obter muitos registros. Neste exemplo, um navegador faz cinco solicitações para carregar uma página de produto de um fone de ouvido com seu preço. Uma aplicação usa o mesmo proxy para chamar a API de catálogo daquele varejista e obtém cinco preços de produtos em uma solicitação. Essa é a API do varejista, que fornece dados de produtos. Se ela retornar o catálogo em páginas, cada página precisará de outra solicitação. Às vezes, é possível aumentar a quantidade de produtos por resposta, desde que a API ofereça essa configuração e retorne todos os dados necessários.

Essa abordagem ajuda a obter mais trabalho útil de um pacote. Carregar repetidamente páginas completas, buscar dados que você já salvou e verificar preços com mais frequência do que o necessário pode esgotar rapidamente a franquia. Obter vários produtos por chamada, salvar resultados e escolher uma frequência adequada de verificação reduz as solicitações necessárias para o mesmo trabalho. Com a mesma carga de trabalho, a franquia pode durar mais dentro da validade do pacote; alternativamente, você pode usá-la para verificar mais produtos.

É útil medir o uso por tarefa concluída. Isso pode significar verificar uma página, obter uma lista completa ou verificar um elemento que aparece após a execução de scripts. Meça a sequência inteira necessária para chegar àquele resultado. Isso inclui carregamentos extras de página que passam facilmente despercebidos quando se contam apenas as URLs iniciais.

Onde esse modelo de preços é útil

Monitoramento programado

O uso de solicitações pode ser associado a verificações regulares. Uma aplicação pode monitorar a disponibilidade de páginas, mudanças em anúncios públicos ou resultados de busca de uma região necessária. Você sabe antecipadamente o número de destinos e a frequência de verificação. Um teste mostra quantas solicitações cada verificação usa e ajuda a estimar o consumo mensal.

Páginas diferentes não precisam ser verificadas com a mesma frequência. Se a informação muda uma vez por dia, verificar a cada minuto geralmente retornará os mesmos dados. Verificações mais frequentes podem ser reservadas para páginas em que detectar uma mudança rapidamente importa. Isso mantém o pacote disponível para as observações de que você precisa.

Coleta de dados por APIs e diretórios

O uso aqui depende de como o site fornece suas informações. Se a lista já contém tudo de que você precisa, não há motivo para abrir cada página de detalhes. As solicitações extras podem ser reservadas para itens com dados ausentes ou registros que mudaram desde a execução anterior. Quanto mais dados necessários você obtiver em uma chamada, menos solicitações a coleta completa exigirá.

Você também precisa considerar o que o serviço faz. Uma API de busca pode retornar resultados já analisados, enquanto um proxy comum deixa o download e o processamento para sua aplicação. São quantidades diferentes de trabalho. Ao comparar preços, verifique o que a resposta contém e o que você ainda precisa fazer por conta própria.

Auditorias de sites e verificações no navegador

Uma auditoria técnica costuma ter uma sequência clara: abrir um endereço, verificar a resposta, seguir um redirecionamento se necessário e salvar a constatação. Se a maioria dos endereços for tratada de forma semelhante, um teste facilitará estimar o uso. Uma verificação no navegador pode precisar de mais solicitações porque depende de scripts, imagens e elementos funcionais da página.

Escolha o método de verificação conforme seu propósito. Um cliente simples costuma bastar para ver se uma página responde. Testar um formulário de finalização de compra exige carregar o que o formulário precisa para funcionar. Desativar arquivos necessários reduzirá as solicitações, mas o teste deixará de mostrar a experiência do usuário.

Como os erros e as novas tentativas afetam o uso

Uma solicitação enviada nem sempre retorna os dados necessários. Um site pode retornar um erro, um desafio de acesso ou uma página diferente. Mesmo HTTP 200 não garante que a aplicação recebeu o que queria: o status informa sucesso no nível HTTP, enquanto o conteúdo da resposta precisa de uma verificação separada.

As regras de cobrança dessas solicitações variam. Alguns serviços contabilizam as solicitações enviadas. Outros cobram apenas pelas respostas que atendem à sua definição de conclusão bem-sucedida. Uma API gerenciada pode incluir no preço de uma resposta várias tentativas internas de obter dados. Modos ou recursos adicionais às vezes mudam as regras de cobrança. Portanto, “pagar por solicitação” não significa automaticamente “pagar apenas pelos dados obtidos”.

Uma nova tentativa da sua aplicação é diferente de uma nova tentativa dentro do serviço. Quando a aplicação envia a solicitação novamente, cria uma nova solicitação. Quando o serviço repete um trabalho que você já enviou, essas tentativas podem estar incluídas no preço. Descubra quais tentativas são descontadas do pacote.

Durante um teste, registre três números: tarefas iniciadas, solicitações cobradas e tarefas concluídas. A conclusão depende do propósito. Para coleta de dados, a resposta deve conter os campos necessários e informações suficientemente recentes. Para monitoramento de disponibilidade, detectar corretamente um site indisponível também é uma verificação concluída.

Esses números ajudam a mostrar quanto o trabalho realmente custa. Solicitações baratas podem ter um custo-benefício ruim se as respostas exigirem constantemente outra tentativa ou precisarem ser descartadas. Um serviço mais caro pode fazer parte do trabalho por você. Compare o gasto necessário para obter o resultado exigido, incluindo o trabalho que fica para sua aplicação.

Como calcular o pacote necessário

Primeiro, conte o trabalho planejado: quantos destinos precisam ser processados e com que frequência. Depois, acrescente as solicitações necessárias além da obtenção normal, como as novas tentativas observadas nos testes. Calcule separadamente grupos de páginas que se comportam de forma diferente. Mantenha também uma reserva para o crescimento da carga de trabalho separada, para que as mesmas solicitações extras não sejam adicionadas duas vezes.

Considere um exemplo ilustrativo. Uma aplicação verifica 150 URLs a cada 30 minutos durante 30 dias. Suponha que uma verificação normal use uma solicitação na tarifa selecionada e que as tentativas adicionais aumentem o uso em 5%. Todos os números e preços deste exemplo são hipotéticos; não são resultados de testes de provedores nem uma tarifa da ProxyCompass.

O pacote selecionado deixa uma reserva de 23 200 solicitações. Ela pode cobrir o crescimento da carga de trabalho enquanto o pacote permanecer válido. As novas tentativas esperadas já estão incluídas nas 10 800 tentativas adicionais; essa reserva não deve ser contabilizada novamente como uso dessas mesmas novas tentativas.

Suponha que o pacote custe $10. Ele contém 250 mil solicitações; portanto, o preço nominal por mil é de $0.04. Você paga $10 pelo pacote inteiro. Multiplicar o uso esperado de 226 800 solicitações por essa tarifa resulta em $9.072. Esse é o valor da parte usada, e não o valor da compra: o pacote fixo ainda custou $10.

Agora suponha que, após as tentativas adicionais, a aplicação conclua todas as 216 000 verificações programadas. Mil verificações concluídas custam aproximadamente $0.0463: $10 ÷ 216 000 × 1 000. Esse valor considera tanto as solicitações extras quanto a reserva que você comprou. Se menos verificações forem concluídas, divida o gasto pelo número real delas.

O cálculo funciona da mesma forma para outras tarefas. Na cobrança por uso, multiplique as solicitações faturáveis pela tarifa, considerando quantas solicitações essa tarifa cobre. Com um pacote, use seu preço total de compra. Depois, divida o gasto pelo número de tarefas concluídas. Se vários projetos compartilharem um pacote, decida como distribuir o custo entre eles.

Verifique também se a aplicação consegue concluir o trabalho no prazo. Nosso exemplo exige 7 200 verificações por dia, com uma média de cinco inícios por minuto. Você poderia iniciar todas as 150 verificações juntas a cada meia hora ou distribuí-las pelo intervalo. O uso do pacote seria o mesmo se cada verificação exigisse o número de tentativas pressuposto, mas a carga no início seria diferente. Um limite de conexões ou de frequência de solicitações pode impedir que a primeira programação funcione como planejado.

Como reduzir solicitações desnecessárias

Remova endereços duplicados e salve os resultados à medida que o trabalho avança. Após uma falha, a aplicação deve continuar de onde parou. Se reiniciar a lista inteira a cada vez, as páginas já processadas consumirão o pacote novamente. Mantenha um registro de quais tarefas estão concluídas e quais ainda precisam ser processadas.

Use o método de carregamento necessário para obter os dados. Se o texto necessário já estiver na resposta do servidor, executar um navegador poderá ser desnecessário. Se os dados só aparecerem após a execução de scripts, um download simples poderá não bastar. Em serviços de coleta de dados, o modo de navegador e recursos extras às vezes usam mais créditos ou têm outra tarifa. Portanto, um crédito nem sempre equivale a uma solicitação.

Reduzir o tamanho da resposta nem sempre economiza solicitações. Se o provedor contabilizar chamadas HTTP, uma resposta curta poderá usar tantas solicitações quanto uma longa. Para reduzir a contagem, você pode verificar dados inalterados com menos frequência, reutilizar um resultado salvo ou obter vários registros em uma chamada de API. As informações ainda precisam ser recentes o suficiente para sua tarefa.

Limite as novas tentativas e considere por que a solicitação falhou. Se um site estiver temporariamente indisponível ou pedir que você diminua o ritmo, uma nova tentativa imediata poderá retornar a mesma resposta e gastar outra solicitação. Pausar ou reduzir a frequência pode ser mais útil. Tenha cuidado especial com ações que criam ou alteram dados: verifique o resultado da primeira tentativa antes de enviar novamente. Uma resposta perdida não significa que o servidor não fez nada.

Depois de fazer alterações, verifique os resultados e o uso. A contagem de solicitações pode ter caído porque a aplicação deixou de fazer parte do trabalho. Uma redução é útil quando você continua obtendo os dados necessários, com a mesma completude e atualização, usando menos solicitações.

O que verificar ao escolher uma tarifa

Primeiro, certifique-se de que o serviço funciona para seus sites e sua aplicação. O tipo de proxy, os países disponíveis, o comportamento das sessões e o acesso às páginas necessárias pelos IPs fornecidos importam. Depois, compare o trabalho incluído: quem carrega a página, executa o navegador, extrai os dados e repete as tentativas que falharam? Isso ajuda a explicar por que dois serviços cobram preços diferentes por solicitação.

Verifique o prazo de validade do pacote, as regras de recarga e o tratamento das solicitações não utilizadas. Um pacote grande com preço menor por solicitação oferece um bom custo-benefício se você puder usá-lo no trabalho necessário dentro do prazo. Se parte das solicitações compradas não for usada, o custo por tarefa concluída poderá ser maior do que com um pacote menor.

Para uma comparação, selecione páginas típicas do seu projeto, incluindo aquelas que costumam causar dificuldades. Registre o tempo gasto, as solicitações usadas, os resultados obtidos e as configurações da aplicação. Esse teste indicará o tamanho do pacote necessário, o custo aproximado do trabalho e se você consegue concluí-lo no prazo.