Apache n'est pas un bon choix pour un reverse proxy http / https :
pas de gestion différencié des timeout côté client et côté serveur
modèle un thread / proc par requête (pas de pool)
pas de check pour vérifier la santé du backend
pas de maximum de connexions par backend
pas de stratégie de replie en cas de problème
Il vaut largement mieux utiliser haproxy, nginx ou varnish qui pourrons de plus vous servir à d'autres choses (mode pop / imap pour nginx, mode tcp pour haproxy, cache pour varnish).
Personnellement mon coeur me pousse vers haproxy
Petite exemple amusant :
On veux rediriger les connexions mysql adressé sur localhost vers une machine distante de façon transparente pour l'utilisateur.
Le problème est que la libmysqlclient convertie les appels vers localhost en connexion sur la socket unix par défaut. Autrement une simple règle de firewall ne suffit pas. Il faut pouvoir rediriger les connexions à la socket unix vers le port 3306 d'une machine distante.
listen mysql /tmp/mysql.sock
mode tcp
timeout server 1h
timeout client 30s
server sql0 sqlhost:3306 maxconn 500
# Haproxy
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Gérer plusieurs services de façon transparente. Évalué à 8.
Apache n'est pas un bon choix pour un reverse proxy http / https :
Il vaut largement mieux utiliser haproxy, nginx ou varnish qui pourrons de plus vous servir à d'autres choses (mode pop / imap pour nginx, mode tcp pour haproxy, cache pour varnish).
Personnellement mon coeur me pousse vers haproxy
Petite exemple amusant :
On veux rediriger les connexions mysql adressé sur localhost vers une machine distante de façon transparente pour l'utilisateur.
Le problème est que la libmysqlclient convertie les appels vers localhost en connexion sur la socket unix par défaut. Autrement une simple règle de firewall ne suffit pas. Il faut pouvoir rediriger les connexions à la socket unix vers le port 3306 d'une machine distante.
Et hop merki haproxy