Otimizando o sistema operacional para solicitações HTTP

Question

Nós fazemos muitas solicitações HTTP. Recentemente, começamos a pensar em otimizações no nível do SO para fazer mais solicitações de uma única máquina.

Para verificar o desempenho do nosso sistema operacional, criei uma pequena referência para comparar as coisas em diferentes máquinas. O benchmark usa curl -w assim:

#!/bin/bash
for (( ; ; ))
do
  curl $URL -o /dev/null -s -w "SIZE:   %{size_download}    SPEED: %{speed_download}    LOOKUP: %{time_namelookup}  CONNECT:    %{time_connect} START:  %{time_starttransfer}   TOTAL:  %{time_total}\n"
done

Agora eu corri para um único URL. Os resultados são os seguintes: De minha máquina dev local (conectada com fibra):

SPEED (b/sec)   LOOKUP  CONNECT START   TOTAL
13,331.2481     0.0022  0.0228  0.2163  0.2175

Em um de nossos servidores de produção (com virtualização XEN), os resultados são um pouco diferentes:

SPEED (b/sec)   LOOKUP  CONNECT START   TOTAL
22,764.7700     0.0093  0.0455  0.1318  0.1334

E em outro servidor não relacionado, sem virtualização XEN (data center diferente, continente diferente, além do recurso)

SPEED (b/sec)   LOOKUP  CONNECT START   TOTAL
32,821.3569     0.0004  0.0080  0.1608  0.1672

Como você pode ver, o desempenho em nosso servidor de produção está longe de ser satisfatório. A taxa de transferência de dados é mais rápida do que no meu laptop local, mas a latência está nos matando. Como buscamos recursos HTTP cujo tamanho é pequeno, precisamos otimizar essa latência.

Alguma ideia de por onde começar?

UPDATE: não se trata de escalar um servidor web. É sobre o escalonamento de solicitações da Web.

    

Answer 1

Este é um problema bem estudado ("rastreamento da web de alto desempenho"), com muitas pesquisas disponíveis: link ... sim, eu estou trapaceando, mas honestamente, você deve ler a literatura primeiro.

Com base em minha própria experiência com a construção desse tipo de sistema no passado: você não pode vencer a velocidade da luz, então, de uma forma ou de outra, você incorrerá nela. O que você pode fazer é otimizar como e quando agendar buscas de recursos. Por exemplo, você pode ter subsistemas otimizados para lidar com partes do problema - por exemplo, Resolução de DNS. Você pode pré-resolver nomes e conectar-se diretamente ao endereço IP (basta adicionar o cabeçalho de host correto). Depois disso, você terá que incorrer no custo de conexão TCP, não há como evitar isso. Dito isso, se você tiver várias solicitações para o mesmo host, poderá aproveitá-las para serializar várias solicitações em uma conexão existente: isso ajuda a amortizar os custos do handshake TCP / TLS e oferece melhor desempenho de ponta a ponta. A partir daí, você precisa subir a escada do protocolo: às vezes, é possível rastrear cadeias de redirecionamento e lembrar o último local para pular os redirecionamentos extras no futuro (basta ter um fallback). Na verdade, o mesmo se aplica ao DNS. Você pode implementar uma estratégia otimista e conectar-se diretamente ao IP e, em seguida, usar um retorno se isso falhar. Para o TLS, você pode armazenar tickets de sessão e outros metadados para obter uma reconexão mais rápida (isto é, supondo que você se reconecte com freqüência suficiente).

tl; dr: Não estou adicionando nada de novo aqui, todas as dicas acima (e mais) são abordadas na pesquisa disponível. Pegue um café, passe algum tempo lendo os documentos existentes!

    

Answer 2

Não sei para onde estão indo os seus pedidos http, mas você pode ver se o (s) servidor (es) da Web em questão é compatível com SPDY.

Desenvolvido no Google, o SPDY é uma tentativa de canalizar várias solicitações https para maior taxa de transferência e menor latência.

Eu também gostaria de destacar as recomendações acima relacionadas à otimização do DNS. Você realmente quer configurar um DNS de encaminhamento de cache para tornar as coisas mais rápidas. Se você tem algum controle sobre o TTL do (s) servidor (es), vale a pena aumentá-los até onde você estiver confortável.