quanta RAM para conteúdo pesado estático está servindo?

Question

Eu quero criar um servidor para meu conteúdo estático.
Eu preciso servir alguns arquivos de 3-10 mb - muito. (Eu também colocarei neste servidor alguns arquivos .js e .css e imagens dos meus sites).
Pensei no nginx e no G-WAN ( link ).
O que eu não sei é quais recursos são necessários para servir conteúdo estático? Quanta RAM é usada para cada transferência de arquivos?
Se eu for com um VPS de 256 mb (ou 512 mb) com boa porta e banda enorme, quantos hits / segundos eu poderei atender (3-10 mb)? (Eu sei "depende" - mas por favor me dê uma estimativa aproximada baseada na experiência ou na teoria). Não há muitos arquivos, apenas baixados com frequência - devo considerar o armazenamento em cache, ou isso só usará minha memória necessária para atender hits?

    

Answer 1

Se você estiver usando o nginx, estará falando apenas alguns KB de sobrecarga por conexão ativa. Se você estiver usando algo como o Apache, terá um thread por conexão, o que significa centenas de KB ou até megabytes por conexão.

No entanto, o nginx não suporta IO assíncrono disco no Linux (porque o IO do disco assíncrono no Linux é basicamente terrivelmente danificado por design). Portanto, você terá que executar muitos processos de trabalho do nginx, já que toda leitura de disco pode bloquear potencialmente todo um processo de trabalho. Se você estiver usando o FreeBSD, isso não é um problema, e o nginx fará maravilhas com o disco assíncrono e o IO de rede. Mas você pode querer ficar com o Apache se estiver usando o Linux para este projeto.

Mas, na verdade, a coisa mais importante é o cache de disco, em vez do servidor da web que você escolhe. Você quer muita RAM livre para que o sistema operacional armazene esses arquivos em cache e faça as leituras muito rápidas. Se o "hot set" for mais do que 8 GB, considere obter menos RAM e um SSD barato, pois a relação custo / benefício provavelmente será melhor.

Finalmente, considere usar um CDN para descarregar isso e obter um servidor realmente barato. Servir arquivos estáticos é o que eles fazem, e eles fazem isso muito rápido e muito barato. O SimpleCDN tem os preços mais baixos, mas o MaxCDN, o Rackspace, o Amazon, etc., todos são grandes players no segmento inferior do espaço do CDN.

    

Answer 2

Se o sistema operacional puder armazenar em cache a parte ativa do conteúdo em memória RAM, ele não usará o disco e servirá as coisas muito rapidamente. Centenas de solicitações por segundo devem ser possíveis em um VPS, você provavelmente saturará a rede bem antes de entrar nos limites da CPU.

Se o conteúdo não couber no RAM, o disco IO (busca, taxa de transferência, fragmentação do sistema de arquivos) entrará em ação e a equação será alterada.

O servidor da Web adicionará uma sobrecarga de memória por cliente, mas o nginx poderá fazer isso em alguns kilobytes por conexão.

Espero que estes indicadores possam ajudá-lo.

    

Answer 3

what resources are needed for serving static content? How much RAM is used for each file transfer?

Primeiro, para o mesmo número de trabalhadores, o G-WAN v4.7 + está usando muito menos memória RAM do que o Nginx na inicialização:

> Server 'nginx' process topology:
---------------------------------------------
  6] pid:21228 Process RAM: 0.77 MB
  5] pid:21229 Process RAM: 2.44 MB
  4] pid:21230 Process RAM: 2.44 MB
  3] pid:21231 Process RAM: 2.44 MB
  2] pid:21232 Process RAM: 2.44 MB
  1] pid:21233 Process RAM: 2.44 MB
  0] pid:21234 Process RAM: 2.44 MB
---------------------------------------------
Total 'nginx' server footprint: 15.39 MB

> Server 'gwan' process topology:
---------------------------------------------
  6] pid:6054 Thread
  5] pid:6053 Thread
  4] pid:6052 Thread
  3] pid:6051 Thread
  2] pid:6050 Thread
  1] pid:6049 Thread
  0] pid:5839 Process RAM: 2.19 MB
---------------------------------------------
Total 'gwan' server footprint: 2.19 MB

O G-WAN usa encadeamentos (um por núcleo normalmente), o Nginx usa processos (um por núcleo normalmente) e processos arrastam mais sobrecarga, exigem sincronização via memória compartilhada, etc. Ambos usam o modelo "assíncrono" de manipulação de eventos.

Note que o G-WAN pode crescer automaticamente para mais de 1 milhão de conexões simultâneas enquanto o Nginx está limitado a suas worker_connections settings (definido em apenas 4096 no teste ab.c acima).

what is not clear to me is if there is memory overhead per connection: i.e. if nginx or gwan consumes memory for every hit?

O conto é que o G-WAN v4.7 + (onde o cache de memória está desabilitado por padrão) consome muito menos RAM que o Nginx, para todos os tamanhos de arquivo, enquanto atende mais solicitações por segundo.

A longa história é que, enquanto o Nginx consome mais e mais memória, mesmo com novas solicitações keep-alived de HTTP, o uso de memória do G-WAN pode permanecer estável para solicitações keep-alived, e cresce muito menos do que para Nginx. solicitações de keep-alived.

Nosso wrapper weighttp ab.c mede o consumo de memória do aplicativo do servidor e do sistema durante a duração do teste. E isso mostra que o Nginx coloca um peso maior no sistema em relação ao consumo de recursos de memória.

Isso se deve à maneira como cada servidor da Web está lidando com solicitações e alocando memória.

If I have 10 request of a 5 mb file in the same time, will this mean there will be 50mb memory used for serving it? Maybe + memory for threads (I don't know if nginx or gwan uses threads for evey connection).

Os dois servidores (Nginx e G-WAN) usam sendfile() para que o kernel (em vez do aplicativo) esteja alocando os recursos para E / S.

Os servidores da Web ainda alocarão recursos, mas isso é para manter o contexto de cada conexão, em vez de para armazenar em buffer a E / S do disco.

Portanto, o consumo mínimo depende do tamanho dos fragmentos de arquivos enviados em cada chamada sendfile() , e não diretamente do tamanho total do arquivo.

O tamanho totfile tem uma influência no longo prazo para altas simultaneões, mas isso é devido à quantidade de pedaços que precisam ser armazenados em cache pelo kernel.

Mais alguma pergunta, entre em contato conosco no G-WAN. Investimos pesadamente em aplicações semelhantes à CDN.