Os aplicativos da web são limitados pela quantidade de memória ou pela velocidade do servidor de banco de dados no lado do servidor?

5

Muitos sites na Web fazem apenas operações de CRUD (criar, ler, atualizar, excluir) no banco de dados para URLs diferentes. Suponha que tenhamos uma solução de 3 camadas com o servidor de banco de dados em um servidor dedicado e o servidor da Web em outro servidor. Esta questão não é sobre o servidor de banco de dados, mas o servidor web.

O servidor web usa conteúdo dinâmico para executar algum código para cada solicitação e está se comunicando com o servidor de banco de dados.

Quais devem ser as limitações do servidor da Web se os aplicativos da Web não forem pesados para computação com carga pesada? O aplicativo da Web não deveria estar limitado à velocidade do servidor de banco de dados? ou é limitado pela quantidade de memória? Com a velocidade das CPUs hoje eu não acho que a velocidade da CPU dos servidores web seja a limitação.

Para servidores web de conteúdo estático, como Nginx e Lighttpd, o servidor da web quase sempre usa pouca memória e é limitado pela velocidade de disco-IO. Mas como é para o conteúdo dinâmico?

    
por Jonas 23.04.2011 / 11:52
fonte

5 respostas

6

Depende da sua configuração. Supondo que você tenha servidores separados para o banco de dados, servidores separados para arquivos estáticos e talvez memcache separado, a camada da Web é definitivamente vinculada à CPU (a menos que você esteja fazendo algo muito estranho). Claro, se você tentar combinar mais de um desses serviços com o servidor web, então YMMV.

No entanto, observe que há um problema C10K e, a menos que você o resolva corretamente, a camada da web será recursos do sistema vinculados.

    
por 23.04.2011 / 13:33
fonte
4

Depende.

Em primeiro lugar, as aplicações nunca são limitadas por memória, disco, CPU e assim por diante. Sistemas inteiros são. Normalmente, para aplicações, usamos uma terminologia diferente, como uso intensivo de CPU , uso intensivo de memória e assim por diante. Você também pode usar termos como centrado no banco de dados .

Não há respostas gerais para sua pergunta, infelizmente. Um aplicativo da Web que processa vídeos exige muito da CPU, enquanto um site muito grande que usa uma fila na memória ou toneladas de armazenamento em cache seria intensivo em memória , etc.

Quando olhamos para sistemas inteiros, a resposta se torna um pouco mais interessante. Um pouco sobre o fundo: Eu fui um arquiteto sênior em vários grandes sites. A maneira como o código é desenvolvido, na minha experiência, é o seguinte:

  1. O aplicativo é arquitetado tendo em mente se é esperado que ele use a CPU intensivamente ou faça uso intensivo da memória. Além disso, CDNs como a Akamai estão planejados neste estágio.
  2. O hardware está planejado em um nível experimental sob as suposições do arquiteto.
  3. O aplicativo é desenvolvido de acordo com a arquitetura sem grandes otimizações .
  4. A criação de perfis no teste de carga é executada. Os principais gargalos são identificados e otimizações relevantes são inseridas na base de código.
  5. Uma nova rodada de testes de carga é executada e o hardware é adaptado - o ideal é que você deseje aplicativos sem gargalos - o gargalo esperado seria o próprio servidor web (por exemplo, o Apache ou o IIS morre devido a muitas conexões, independentemente do aplicativo) .
  6. Com base nos resultados de 4. e 5. e nas estimativas de tráfego, o número de servidores da Web é decidido.
  7. Neste ponto, como você pode expandir servidores da Web, o afunilamento será o servidor de banco de dados.

Como você pode ver, a resposta não é simples. Não existe uma regra firme geral nesses sistemas e, na verdade, gastos significativos são esperados para garantir que todos os possíveis gargalos sejam eliminados e o aplicativo da Web possa suportar o tráfego esperado com facilidade.

    
por 23.04.2011 / 12:52
fonte
0

Você quer dizer limite de CPU versus limite de E / S, certo? O acesso à memória e a E / S são os mesmos devido às implementações de memória virtual e não é possível prever se algum processo é desativado ou não em um determinado momento.

Os servidores da Web geralmente são limitados por E / S, o que significa que eles passam a maior parte do tempo aguardando a resposta da rede do servidor de back-end (banco de dados).

Pense nisso assim:

  • Se o sistema fosse mais rápido se você atualizasse a CPU, então ela estaria ligada à CPU.
  • Se discos ou redes melhores o tornassem melhor, então seria um limite de E / S.
  • Se trocar muito, você precisará de mais RAM e será vinculado a E / S ou "comprar mais RAM":)

Mais uma vez, as pessoas falam principalmente sobre CPU versus E / S. Os problemas de memória estão incluídos no conceito I / O bound :

The I/O bound state is considered undesirable because it means that the CPU must stall its operation while waiting for data to be loaded or unloaded from main memory or secondary storage.

    
por 23.04.2011 / 12:01
fonte
0

Qualquer coisa pode ser um gargalo se for inadequado o suficiente. Se você aluga espaço em um data center de qualidade, deve ser capaz de cuidar da conexão com a Internet e do hardware do roteador. Os bancos de dados podem ser dimensionados com hardware, algumas versões de software (a versão gratuita do SQL Server tem limitações, independentemente do hardware), design e ajuste de desempenho. Os usuários simultâneos em seu servidor da Web provavelmente precisarão de mais memória do que qualquer coisa.

Tivemos um aplicativo da web de entrada de horário corporativo que seria sobrecarregado no final do mês com todos que estavam acompanhando e fazendo edições. Os servidores da web eram balanceados por carga. Havia 1 servidor de db (conhecido como The Beast), 1-2 servidores de aplicativos e os servidores da web variavam de 2-4. O escritório central tinha vários usuários de aplicativos de desktop, então eles usaram muito do primeiro servidor de aplicativos. A estimativa aproximada foi de 70 usuários simultâneos por servidor web. Por fim, os servidores da Web evoluíram para servidores virtuais, para facilitar a adição de servidores reduzidos e a alocação de recursos. O banco de dados levou uma surra porque esse aplicativo colocava tudo no banco de dados, incluindo as configurações de quase todos os objetos em todas as páginas da web (todas as páginas eram personalizáveis pelos analistas).

    
por 23.04.2011 / 15:31
fonte
-2

Por favor, compre e leia o link imediatamente.

Aqui estão algumas fontes para o livro.

link

Todas as suas suposições estão erradas.

O afunilamento é a área de trabalho do usuário.

Uma vez que você construa material suficiente para passar pelo gargalo de download da área de trabalho, o próximo afunilamento que aparece é geralmente a memória do lado do servidor. Mas isso é facilmente resolvido com hardware. Depois disso, é o tempo do processador do lado do servidor.

    
por 23.04.2011 / 14:22
fonte