Imagines que la page d'acceuil de linuxfr soit gérer par un truc dynamique, à chaque connexion le moteur doit être exécuter. Si la page html est généré uniquement en cas de modification, 99% du temps, le serveur sert une page statique.
Dans le cas de reverse proxy, il me semble qu'il y a un problème pour prévenir le truc de devant par un "ça a bougé". Il faut fonctionner avec des timeout court si on veut de la réactivité, c'est pas forcément top, car le moteur sera appelé pour rien.
C'est pour cela que je parle de performance à l'époque du passage à templeet, les perf avait exploser avec cette technique (même si il y a avait du php dessous).
Ce n'est pas parce que le code est compilé qu'il ne peut pas avoir d'énorme faiblesse dans l'architecture, vu la complexité du web. Cela serait bête qu'une seul personne puisse faire un DOS sur un site web.
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3. Dernière modification le 29 juin 2012 à 17:50.
Imagines que la page d'acceuil de linuxfr soit gérer par un truc dynamique, à chaque connexion le moteur doit être exécuter. Si la page html est généré uniquement en cas de modification, 99% du temps, le serveur sert une page statique.
Dans le cas de reverse proxy, il me semble qu'il y a un problème pour prévenir le truc de devant par un "ça a bougé". Il faut fonctionner avec des timeout court si on veut de la réactivité, c'est pas forcément top, car le moteur sera appelé pour rien.
C'est pour cela que je parle de performance à l'époque du passage à templeet, les perf avait exploser avec cette technique (même si il y a avait du php dessous).
Ce n'est pas parce que le code est compilé qu'il ne peut pas avoir d'énorme faiblesse dans l'architecture, vu la complexité du web. Cela serait bête qu'une seul personne puisse faire un DOS sur un site web.
"La première sécurité est la liberté"