Servidor http super simples de alto desempenho

3

Estou construindo uma aplicação web de redução de URL e gostaria de conhecer a melhor arquitetura para fazer isso, a fim de fornecer um serviço rápido e confiável.

Eu gostaria de ter dois serviços separados em máquinas diferentes.

  • A primeira máquina terá o aplicação em si com um apache, nginx, seja o que for ..
  • O segundo vai contém o banco de dados.
  • O terceiro será aquele que será responsável por lidar com o URL curto petições.

UPDATE :

O serviço não é um encurtador de URL. Foi mais fácil explicar isso assim.

Eu só preciso de uma máquina que receba uma consulta http e insira um registro em um banco de dados. E eu preciso dessa máquina para fazer essa tarefa simples de uma maneira muito eficiente. O sistema rodará no linux (ainda não conheço a distro) e estou totalmente aberto a qualquer idioma ou tecnologia. Eu estava pensando em usar Yaws, Tornado ou Snap para esse serviço, mas eu ainda não sei e é hora de planejar a arquitetura para essa parte. O banco de dados será construído no Hadoop.

Para a terceira máquina, eu só preciso aceitar um tipo de petição HTTP (GET www.domain.com/shorturl), mas ela precisa ser muito rápida e estável o suficiente.

    
por masylum 03.06.2010 / 20:35

3 respostas

2

Você realmente acha que há necessidade de outro redutor de URL? Há apenas tantos deles em torno de ... a menos que você tenha conseguido por acaso adquirir um nome de domínio muito curto e apropriado, eu não acho que seu site vai ser notado por qualquer pessoa. Apenas meus dois centavos, claro.

De qualquer forma, para a parte técnica:

  • Em que idioma você vai escrever sua inscrição?
  • Em qual sistema operacional você planeja executá-lo?
  • Você usará softwares gratuitos ou comerciais?

É difícil responder à sua pergunta sem saber disso.

A única resposta que pode fazer algum sentido aqui é "evitar Java como uma praga". Um servidor de aplicativos Java é um exagero para muitos aplicativos, e com certeza seria um exagero para um tão simples.

Eu iria para Linux / Apache / MySQL / PHP aqui ... if Eu poderia pensar em algum bom motivo para iniciar o projeto, é claro.

Editar:

Ok, agora faz um pouco mais de sentido; mas a sugestão para começar o mais simples possível e então se preocupar com a ampliação ainda é válida. Se sua aplicação realmente é simples, qualquer combinação de servidor / idioma / banco de dados decente deve ser capaz de processar lotes de solicitações por segundo em hardware moderno (mas eu ainda sugiro strongmente evitando Java).

Se o desempenho é primordial, eu usaria um aplicativo CGI escrito em C; que será a solução mais rápida possível, com ordens de magnitude mais rápidas do que qualquer linguagem interpretada ou de VM; e tê-lo fazendo simples INSERTs e SELECTs para um banco de dados não deve ser tão difícil. Mas acho que o LAMP é mais que suficiente para as suas necessidades ... eles realmente executam o Facebook nele, você sabe?

    
por 03.06.2010 / 20:59
0

Estes são apenas dados de gravação, ou eles também enviam de volta algo de interesse? Se eles estão apenas registrando, então basta usar o apache e lançar os logs do apache no hadoop. Se eles tiverem que retornar algum tipo de dado, não está claro para mim como eles obtêm os dados que estão retornando.

Ainda assim, o apache configurado para retornar um arquivo estático para qualquer solicitação é muito rápido.

    
por 16.07.2010 / 10:48
0

Primeiro, eu sei que você disse que não é um encurtador de URL, mas se é algo parecido, um RDBMS é uma maneira terrível de armazenar esses dados; já que não há relação real entre quaisquer dois dados, você quer um mecanismo de armazenamento plano. Considere o Mongo (ou Couch, dependendo do espaço real da sua solução).

Quanto à sua solução, tenha cuidado com otimização prematura . Há muitas maneiras de enlouquecer com isso; desde que você perguntou, o mais louco que eu posso pensar de improviso pode ser acender o verniz, escrever todas as suas páginas no VCL, e fazer com que ele se conecte ao memcache no backend para armazenar e recuperar os dados correspondentes. Mas, realisticamente, isso é loucura, a menos que você esteja sob cargas absurdamente patentes.

    
por 14.04.2011 / 13:43