Tu peux en discuter avec le mec d'haproxy si tu veux, son design single process est actuellement le proxy le plus rapide disponible pour un cout CPU ridicule.
je vois pas ce que processus unique ou non, que ce soit un proxy ou un lecteur audio ou un livre de schtroumph y change quoi que ce soit
Une appli standard a tout intéret à conserver son état interne quelque part et à disposer en permanence de tous les éléments pour comprendre et analyser cet état.
Un proxy n'a aucun intéret à faire celà, il doit faire de la mise en relation le plus rapidement possible entre des clients et des serveurs. A partir de la une question comme "comment on en est arrivé là" ne l'interresse pas. Pour être capable de recharger dynamiquement une config un proxy devrait être capable de comprendre pour quel raison il est dans l'état présent, de réinterpréter l'état en fonction de la nouvelle config et de notifier de façon transparente le client et le serveur des décisions qu'il a prise. Sur un proxy générique comme haproxy c'est tout simplement impossible (ne serait-ce que de convaincre un autre serveur http de reprendre une session modifiée comme si c'était une des siennes ca va être coton, à moins d'en avoir rien à faire de la sécurité du bigniou).
Donc un proxy raisonnablement générique n'a pas vraiment d'autre choix que de redémarrer à chaque changement de config. Et si on doit redémarrer ET que l'on est en architecture processus unique ben paf le systemd.
1* il y a un déjà un wrapper
Pas encore il est en cours d'écriture
2* celui-ci agit mal
Vu le chemin choisi, il n'agira pas plus mal qu'un controlleur NGINX
3* le patch proposé contient des if (systemd) ce qui semble absurde.
Pas plus absurde qu'autre chose. Sur un init classique je n'ai pas besoin de l'overhead lié à systemd - donc autant s'en passer. Surtout que généralement quand on utilise haproxy c'est que l'on veut utiliser jusqu'à la dernière goutte de CPU disponible pour créer des connexions. Personellement je serais même pour un configure --without-systemd (ce qui j'imagine dans ta vision serait encore pire).
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 9.
je vois pas pourquoi, c'est un choix de design
Tu peux en discuter avec le mec d'haproxy si tu veux, son design single process est actuellement le proxy le plus rapide disponible pour un cout CPU ridicule.
je vois pas ce que processus unique ou non, que ce soit un proxy ou un lecteur audio ou un livre de schtroumph y change quoi que ce soit
Une appli standard a tout intéret à conserver son état interne quelque part et à disposer en permanence de tous les éléments pour comprendre et analyser cet état.
Un proxy n'a aucun intéret à faire celà, il doit faire de la mise en relation le plus rapidement possible entre des clients et des serveurs. A partir de la une question comme "comment on en est arrivé là" ne l'interresse pas. Pour être capable de recharger dynamiquement une config un proxy devrait être capable de comprendre pour quel raison il est dans l'état présent, de réinterpréter l'état en fonction de la nouvelle config et de notifier de façon transparente le client et le serveur des décisions qu'il a prise. Sur un proxy générique comme haproxy c'est tout simplement impossible (ne serait-ce que de convaincre un autre serveur http de reprendre une session modifiée comme si c'était une des siennes ca va être coton, à moins d'en avoir rien à faire de la sécurité du bigniou).
Donc un proxy raisonnablement générique n'a pas vraiment d'autre choix que de redémarrer à chaque changement de config. Et si on doit redémarrer ET que l'on est en architecture processus unique ben paf le systemd.
Pas encore il est en cours d'écriture
Vu le chemin choisi, il n'agira pas plus mal qu'un controlleur NGINX
Pas plus absurde qu'autre chose. Sur un init classique je n'ai pas besoin de l'overhead lié à systemd - donc autant s'en passer. Surtout que généralement quand on utilise haproxy c'est que l'on veut utiliser jusqu'à la dernière goutte de CPU disponible pour créer des connexions. Personellement je serais même pour un configure --without-systemd (ce qui j'imagine dans ta vision serait encore pire).