Forum général.général Lighttpd en reverse proxy d'Apache2: très lent

Posté par  . Licence CC By‑SA.
Étiquettes :
1
4
nov.
2013

Hello tous!

Je suis face à un phénomène étrange que j'aimerais vous soumettre: j'ai installé un lighttpd en reverse proxy devant un apache2 qui sert un site web relativement simple en PHP. Lighttpd et Apache2 tournent dans 2 containers OpenVZ hébergés sur la même machine physique. Je ne suis pas satisfait du tout de la performance que j'observe.

Ce qui me laisse penser qu'il y a un problème, c'est que lorsque je contourne le reverse proxy grâce à ssh -D (drôlement pratique ça) et un firefox paramétré en conséquence, le site répond quasiment 10 fois plus vite (merci ApacheBench). J'imagine donc que le problème pourrait venir de la configuration de lighttpd, dont voilà le bout de lighttpd.conf concerné:

$HTTP["host"] == "XXXXXXXXXXXX" {
  $SERVER["socket"] == "0.0.0.0:443" {
    ssl.pemfile = "/etc/lighttpd/certs/XXXXXXXXXXXX.pem"
  }
  proxy.server  = ( "" => ( ( "host" => "X.Y.Z.T", "port" => 80 ) ) )
}

Indice: lorsque je regarde l'onglet Network de firebug ou équivalent, j'observe un délais de 5 secondes avant l'établissement de la connexion pour certains fichiers (js en l'occurrence, mais j'ai l'impression que ça change parfois). Ce délais est absent lorsque je me connecte via le proxy SSH, ce qui explique que la page est bien plus réactive.

Est-ce que par chance ça vous parlerait ? Vous auriez des idées pour que je puisse comprendre ce qui se passe ?

Merci bcp !

Aurel.

  • # DNS, OCSP, chiffrement, overhead

    Posté par  (Mastodon) . Évalué à 2.

    Avec ta description,

    • Dans l’ordre, je regarderai les conf DNS sur les 2 VZ, que tout soit bien résolu dans les 2 sens et sans délai (domaine → IP, IP → domaine), au pire essaie de remplir les /etc/hosts avec ce qu’il faut pour que les machines de ton infra se « connaissent ».
    • Vérifie que ton navigateur ne fait pas de requêtes OCSP ou autre tentant de valider le certificat et qui tombe en timeout. Le chiffrement est-il fait uniquement par le serveur lighthttpd ? Les 2 auquel cas, le reverse-proxy se tape le double de boulot ? Est-il nécessaire de passer par un reverse ? Dans ce cas qu’elle est la valeur ajoutée du apache par rapport à un php-fcgi ?
    • Tes VZ sont-ils bien dimensionnés, ne se montent-il pas sur les pieds en tournant en même temps à chaque requête ?

    • [^] # Re: DNS, OCSP, chiffrement, overhead

      Posté par  . Évalué à 1.

      Merci beaucoup pour tes suggestions.
      - Tout semble bon côté DNS
      - Le chiffrement est optionnel (uniquement jusqu'au reverse proxy) et la lenteur est observée avec et sans lui
      - les VZ sont bien plus puissante que ce qui est nécessaire. iotop et top sur l’hôte physique me donne l'impression que ce dernier se repose tranquillement.

      • [^] # Re: DNS, OCSP, chiffrement, overhead

        Posté par  (Mastodon) . Évalué à 2.

        Tu as regardé touts les compteurs openvz, je me souviens avoir eu des effets de bords sur une limite qui paraissait sans importance, mais qui avait des effets de bords désastreux sur les performances alors que l’hôte ne faisait rien évidemment. Comment tes conteneurs communiquent-ils entre eux (gros bridge sur l’hôte ?, switch logiciel, cartes réseaux dédiées ?).

        Je précise que ça fait assez longtemps que je n’ai pas remis le nez dans OpenVZ, donc les détails me sont un peu sortis de l’esprit.

        • [^] # Re: DNS, OCSP, chiffrement, overhead

          Posté par  . Évalué à 1.

          Je viens de trouver l'origine du problème: apache2 avait un KeepAliveTimeout de 5s. En le passant à 0s, ça fonce.

          KeepAliveTimeout: Number of seconds to wait for the next request from the same client on the same connection.

          Puisque toutes les requêtes proviennent du reverse proxy, il vaut mieux ne pas attendre du tout entre deux. Un vrai coup de bol d'être tombé sur cette solution.

          Merci pour ton aide en tout cas, même si au final c'était tout autre chose !

          Aurel.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.