Estou interessado em implantar um aplicativo django com seu banco de dados. Então, eu gostaria de saber o que você acha que pode ser melhor em termos de desempenho: Três linodos 540 (720) ou um linodo 1440 (2880).
Eu gostaria de ter um para servir conteúdo estático, outro servindo como servidor de aplicativos e o último como servidor de banco de dados.
Qual é o seu conselho?
Eu respeitosamente discordo da sugestão do caos. Ter vários VPS não distribuirá a carga igualmente, e o VPS que serve arquivos estáticos provavelmente será muito pouco usado. Também aumenta a complexidade do seu aplicativo.
Eu uso um servidor grande e gordo, aumente sua capacidade conforme necessário e considere apenas o particionamento quando não for mais viável atualizá-lo.
Eu iria com os três. Se eles acabarem implantados na mesma caixa, você perderá um pouco de desempenho em relação a um único VPS, mas 1) eles provavelmente não serão, 2) será mais fácil ajustá-los para seus papéis do que ajustar um único VPS para todas as suas funções e 3) significa que seu aplicativo será projetado para funções distribuídas a partir do dia 1, para que, se você precisar ficar mais robusto depois, talvez implemente um servidor real para cada função, você estará pronto para isso .
Eu vou contrariar a tendência e dizer que você deve ir com 2-1 para o seu conteúdo na web e outro (provavelmente maior) para o seu banco de dados. Inferno, estou em uma situação em que estou executando um único VPS para todas as minhas necessidades, incluindo DB, com subdomínios apropriados configurados:
static.example.org: lida com conteúdo css, js, images, etc. Defina com keep-alives e expira no futuro. (o conteúdo não expira por um ano ou mais, portanto, nenhuma solicitação adicional é feita. Manter as pessoas ativadas como a maioria das exibições de páginas da Web tentará carregar muitas páginas estáticas, portanto, isso acelerará essas solicitações)
www.example.org: manipule as solicitações dinâmicas. Manter as solicitações estáticas separadas das dinâmicas é importante para a escalabilidade futura de seu sistema - e não é tanto a otimização antecipada. Definir com keep-alives off e expira no futuro. (validação de conteúdo deve ocorrer com conteúdo dinâmico. Ter keep-alives off (ou muito baixo) permite que você salve conexões para solicitações de entrada ... especialmente quando muitos hits serão solicitações de visualização únicas e mais lentas.)
Ter o nginx como seu proxy front-end que lida com as solicitações static.example.org, mas transmite as solicitações www.example.org para um back-end FastCGI (por exemplo), provou ser uma solução rápida para nós - e memória conservadora também. Como alternativa, você pode colocar todo o seu conteúdo estático no Amazon S3 ou algo assim e direcionar suas páginas da Web para isso (com o futuro expirar).
Meu primeiro ponto de expansão provavelmente será mover meu banco de dados para um servidor separado. Eu serei capaz de escalar os processos FastCGI do servidor web para vários sistemas usando nginx com facilidade suficiente - espalhar a carga deve ser razoavelmente fácil ... em teoria.
-Vps tem programas assassinos de memória um ram atribuído exceder. -Não há registros disponíveis para check-in no sistema. - e se nossos aplicativos precisarem de mais memória, exigiremos que os provedores de RAM e Hosting demandem dinheiro. -Melhor ir servidor de db-app de plano de VPS de tamanho médio distribuído.
Tags vps deployment