É um pequeno VPS suficiente para executar um serviço de encurtamento de url?

Question

Eu tive um pequeno serviço de encurtamento de URL orientado para o Japão. Ele foi desligado porque utilizou muitos recursos (tempo de CPU e talvez memória) em um servidor compartilhado. Este foi um par de anos atrás, mas estou interessado em trazer de volta à vida se eu puder pagar.

Estou planejando usar o link desta vez, e queria saber se o menor VPS do linode seria capaz de lidar com o trabalho carga. A maior parte do trabalho é apenas mod_rewrites.

Tudo bem se o site ficar lento, mas não insuportável. Se houver interesse no projeto, poderei atualizar o VPS. Mas estou correto em assumir que, mesmo que o VPS seja inundado, ele não será desativado por afetar o desempenho de outros usuários?

    

Answer 1

Não, o Linode não irá desativá-lo por usar recursos. Eles simplesmente limitarão sua CPU à sua porcentagem. Se ninguém mais estiver usando sua CPU, você também pode usar a CPU, até que o VPS a solicite, então as chances são de que você quase sempre receba mais do que a sua parte. Você pode maximizar a RAM e CPU durante todo o dia e, se o seu site ficar lento, basta atualizar o linode.

A única coisa sobre a qual eles são particulares é o acesso ao HD, já que o poderia afetar os outros, mas isso não parece se aplicar à sua situação.

Eu recomendo linode.

    

Answer 2

Depende realmente de como você escreve o site. Eu posso ver um VPS sendo inundado. Se o seu VPS usar mais recursos do que o alocado, ele poderá ser desligado. Quanto mais leve e veloz for o seu serviço (talvez um backcgi personalizado C ++ fastcgi), melhor será.

    

Answer 3

Como você planeja implementá-lo?

Por quanto tempo os URLs permanecem ativos?

Se você está matando-os após X-muitos dias / meses / o que quer, e você está recebendo apenas algumas centenas de milhares de pedidos por dia, eu anteciparia que um VPS de nível básico de qualquer lugar lidaria com isso.

Eu estaria mais preocupado com o uso da largura de banda, pessoalmente. Eu prefiro um serviço "ilimitado", mas de velocidade limitada, para uma conexão realmente rápida, mas "medida" - os custos são mais fáceis de prever:)

Se é uma implementação realmente simples, digamos que o item encurtado é procurado em um banco de dados, e você retorna um redirecionamento para a URL original - provavelmente não vai usar muita CPU ou RAM - seu único problema deve ser realmente ser armazenamento. Se o URL médio + shortID for, digamos, de 1 KB, e você tiver um milhão de URLs, já estará vendo 1 GB de armazenamento. Estenda seu armazenamento em 1 GB para cada milhão de URLs, e um VPS de nível de entrada do provedor de hospedagem que eu uso ( link ) será desativado em ~ 18 milhões de registros.

    

Answer 4

Site de compressão de URL do Tinyurl. otimização para melhor desempenho no VPS

Muitos VPSs vêm com recursos de CPU paginada e memória mais lenta, em comparação com o que você pode obter em soluções dedicadas. Mesmo o espaço do disco rígido pode ser caro. No entanto u pode tentar fazer melhor C + + ou mesmo perl etc qualquer aplicativo que usa algoritmo justo para o efeito.

U pode considerar uma melhor otimização do algoritmo do seu programa, em vez de tentar obter uma plataforma mais cara ou apenas reescrever o algoritmo em uma linguagem mais rápida (o antigo e o posterior ajudam até certo ponto, no entanto).

Algumas ideias que você pode considerar são o envelhecimento de todos os registros de baixa frequência e alguns registros mais antigos. Você pode obter o contador de visitas armazenado no banco de dados, mas não é recomendado armazenar datas, e sim excluir todos os registros correspondentes no banco de dados atual com vários instantâneos antigos (você não precisará armazenar datas dessa maneira, apenas excluir todos os registros correspondentes no instantâneo antigo e que têm baixa taxa de acerto). Além disso, você pode separar dados antigos e armazená-los em formato compactado "archive" - como usar o prefixo para o tempo de armazenamento, etc. U pode apenas anular registros antigos, preservando os ids e migrando-os para o segundo banco de dados "offline" para agilizar as consultas. p>

Considere também alterar o algoritmo de hashing, mas ele apresenta alguns desafios (como procurar por uma maneira melhor de compactar cadeias de caracteres ou armazenar as URLs mais frequentes ou suas partes em uma tabela de prefixo rápido com "super" ids). praticamente vc pode fazer um desafio (como a wikipedia faz com seu texto aleatório de 100 mb) ou questionar aqui ;-) ou fazer sua própria pesquisa ou até mesmo sair como está, pois ela funcionará de qualquer forma p;

-gl