Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle nous a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre infrastructure est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons la possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème. Nous avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de calcul aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui pourraient être activées sur demande (via une api ?) avec une facturation à l'utilisation.
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Alexandre.
Hello,
Le 21 janvier 2014 12:38, Alexandre infos@opendoc.net a écrit :
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
[...]
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal parfois ça passe très mal ;-)
A part de proposer d'optimiser "Encore" tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
Bien à toi
Le 21/01/14 12:45, seb astien a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre <infos@opendoc.net mailto:infos@opendoc.net> a écrit :
Bonjour à tous, c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question : Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...] Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Yohann,
On 21/01/14 12:48, Yohann QUINTON wrote:
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal parfois ça passe très mal ;-)
A part de proposer d'optimiser "Encore" tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
j'avais oublié de préciser, nous sommes déjà chez Akamai.
Bien à toi
Le 21/01/14 12:45, seb astien a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre <infos@opendoc.net mailto:infos@opendoc.net> a écrit :
Bonjour à tous, c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question : Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...] Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Liste de diffusion du FRsAG http://www.frsag.org/
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
-- Yohann Awedia
Le 21/01/14 12:50, Alexandre a écrit :
Bonjour Yohann,
On 21/01/14 12:48, Yohann QUINTON wrote:
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal parfois ça passe très mal ;-)
A part de proposer d'optimiser "Encore" tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
j'avais oublié de préciser, nous sommes déjà chez Akamai.
Bien à toi
Le 21/01/14 12:45, seb astien a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre <infos@opendoc.net mailto:infos@opendoc.net> a écrit :
Bonjour à tous, c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question : Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...] Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Liste de diffusion du FRsAG http://www.frsag.org/
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Alexandre.
-- Yohann Awedia
Le 21/01/14 12:50, Alexandre a écrit :
Bonjour Yohann,
On 21/01/14 12:48, Yohann QUINTON wrote:
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal parfois ça passe très mal ;-)
A part de proposer d'optimiser "Encore" tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
j'avais oublié de préciser, nous sommes déjà chez Akamai.
Bien à toi
Le 21/01/14 12:45, seb astien a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre <infos@opendoc.net mailto:infos@opendoc.net> a écrit :
Bonjour à tous, c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question : Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...] Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Liste de diffusion du FRsAG http://www.frsag.org/
j'ai jamais testé, mais est-ce qu'un php-fpm en backend pourrait améliorer le temps de réponse du serveur web en front-end ? autre chose, est-ce que délocaliser les contenus statiques types images css, etc. sur un serveur FTP (après tout, c'est prévu pour...) ne pourrait-il pas être plus efficace également ?
qqn a déjà testé ?
Le 21/01/2014 14:00, Alexandre a écrit :
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Alexandre.
-- Yohann Awedia
Le 21/01/14 12:50, Alexandre a écrit :
Bonjour Yohann,
On 21/01/14 12:48, Yohann QUINTON wrote:
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal parfois ça passe très mal ;-)
A part de proposer d'optimiser "Encore" tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
j'avais oublié de préciser, nous sommes déjà chez Akamai.
Bien à toi
Le 21/01/14 12:45, seb astien a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre <infos@opendoc.net mailto:infos@opendoc.net> a écrit :
Bonjour à tous, c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question : Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...] Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 21 janvier 2014 14:17, Pierre `Sn4kY` DOLIDON sn4ky@sn4ky.net a écrit :
j'ai jamais testé, mais est-ce qu'un php-fpm en backend pourrait améliorer le temps de réponse du serveur web en front-end ?
Tu veux dire déporter le FPM sur un autre serveur et s'y connecter via un port ? Intérêt limité, sauf si tu peux avoir en backend des serveurs avec beaucoup de cores et de la RAM (davantage qu'en front, où Apache/NginX ne fait que servir des statiques == peu de boulot). Tu va perdre un peu en latence par contre, mais ça reste infime.
autre chose, est-ce que délocaliser les contenus statiques types images css, etc. sur un serveur FTP (après tout, c'est prévu pour...) ne pourrait-il pas être plus efficace également ?
Et comment les visiteurs y accèdent ? Si tu comptes mettre des URLS en ftp:// dans les pages, très très mauvaise idée (la latence sera très importante).
Sur le front, je conseille de désactiver la mise en cache des images/css/js dans Varnish : cela lui fait toujours ça de gagné en mémoire pour y stocker des contenus dynamiques, et servir du statique depuis le serveur web ne consomme vraiment rien.
Olivier
Le 21 janvier 2014 14:17, Pierre `Sn4kY` DOLIDON sn4ky@sn4ky.net a écrit :
j'ai jamais testé, mais est-ce qu'un php-fpm en backend pourrait améliorer le temps de réponse du serveur web en front-end ? autre chose, est-ce que délocaliser les contenus statiques types images css, etc. sur un serveur FTP (après tout, c'est prévu pour...) ne pourrait-il pas être plus efficace également ?
qqn a déjà testé ?
Testé et adopté ! :-) Sur certaines applications cachable difficilement le load, et l'usage de RAM (si l'option ondemand activé) a été divisé par 2 en passant de php5-cgi à php5-fpm (donc pas de backend distant, mais connexions via socket local). Pour la partie statique sur la même machine, nginx/lighty s'occupe de tout ce qui est css, js, etc. et apache/php-fpm pour le dynamique (contrainte de dev).
Le 21/01/2014 14:00, Alexandre a écrit :
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Est-ce que tu as des stats aux niveaux de tes différents daemon /
serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Alexandre.
-- Yohann Awedia
Le 21/01/14 12:50, Alexandre a écrit :
Bonjour Yohann,
On 21/01/14 12:48, Yohann QUINTON wrote:
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal parfois ça passe très mal ;-)
A part de proposer d'optimiser "Encore" tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
j'avais oublié de préciser, nous sommes déjà chez Akamai.
Bien à toi
Le 21/01/14 12:45, seb astien a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre <infos@opendoc.net mailto:infos@opendoc.net> a écrit :
Bonjour à tous, c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question : Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...] Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with- rackspace-auto-scale/
Le 21/01/2014 14:17, Pierre `Sn4kY` DOLIDON a écrit : [...]
autre chose, est-ce que délocaliser les contenus statiques types images css, etc. sur un serveur FTP (après tout, c'est prévu pour...) ne pourrait-il pas être plus efficace également ?
[...]
Le protocole FTP nécessite une phase de connexion, authentification, même si c'est anonymous. Donc une pohase de question/réponse supplémentaire, qui, sur de nombreux petits fichiers sera rédhibitoire par rapport à du HTTP. Sans parlé du fait que ça sera surement plus embêtant avec les firewall, load balancer, reverses proxy caches...
Donc non, le HTTP a bien été inventé après le FTP, pour faire mieux ce qu'on lui demande sur un site Web...
Hello,
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Tu as une limite de sockets a 65535 ports dispo sur une ip. En mettre plusieurs en // peut déjà passer ce cap.
Après être un poil agressif sur le timeout TCP peut être utile... Selon l'os...
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Y a que moi ou je suis le seul a voir ce qui hurle... php-cgi ... Pourquoi pas php-fpm ?
On peux faire de bonnes choses avec non ?
Xavier
Salut Alexandre,
Un HAProxy avec son maxconn et sa gestion de file d'attente + TCP buffering embedded et voilà :) Tu peux en placer pleins entre toutes tes couches applicatives, et tu vas protéger tes applications durant les pics. On peut t'aider si tu veux ;)
Baptiste
2014/1/22 Xavier Beaudouin kiwi@oav.net:
Hello,
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Tu as une limite de sockets a 65535 ports dispo sur une ip. En mettre plusieurs en // peut déjà passer ce cap.
Après être un poil agressif sur le timeout TCP peut être utile... Selon l'os...
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Y a que moi ou je suis le seul a voir ce qui hurle... php-cgi ... Pourquoi pas php-fpm ?
On peux faire de bonnes choses avec non ?
Xavier
Liste de diffusion du FRsAG http://www.frsag.org/
Conclusion de tout ca, on a recyclé un max de machines pour bouffer la charge. Mais un projet de construction d'un deuxième site est lancé, pour faire de l'actif/actif. J'aimerais bien avec de l'HAProxy '') mais il faut le justifier.
Alex.
On 23/01/14 07:10, Baptiste wrote:
Salut Alexandre,
Un HAProxy avec son maxconn et sa gestion de file d'attente + TCP buffering embedded et voilà :) Tu peux en placer pleins entre toutes tes couches applicatives, et tu vas protéger tes applications durant les pics. On peut t'aider si tu veux ;)
Baptiste
2014/1/22 Xavier Beaudouin kiwi@oav.net:
Hello,
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Tu as une limite de sockets a 65535 ports dispo sur une ip. En mettre plusieurs en // peut déjà passer ce cap.
Après être un poil agressif sur le timeout TCP peut être utile... Selon l'os...
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Y a que moi ou je suis le seul a voir ce qui hurle... php-cgi ... Pourquoi pas php-fpm ?
On peux faire de bonnes choses avec non ?
Xavier
Liste de diffusion du FRsAG http://www.frsag.org/
HAProxy ne se justifie pas! HAProxy est amour pour les sites à fort traffic ou à forts pics. Si Chuck Norris était un load-balancer, il serait HAProxy. Je dirais même plus, "What else?"
Baptiste
2014-01-30 Alexandre infos@opendoc.net:
Conclusion de tout ca, on a recyclé un max de machines pour bouffer la charge. Mais un projet de construction d'un deuxième site est lancé, pour faire de l'actif/actif. J'aimerais bien avec de l'HAProxy '') mais il faut le justifier.
Alex.
On 23/01/14 07:10, Baptiste wrote:
Salut Alexandre,
Un HAProxy avec son maxconn et sa gestion de file d'attente + TCP buffering embedded et voilà :) Tu peux en placer pleins entre toutes tes couches applicatives, et tu vas protéger tes applications durant les pics. On peut t'aider si tu veux ;)
Baptiste
2014/1/22 Xavier Beaudouin kiwi@oav.net:
Hello,
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Tu as une limite de sockets a 65535 ports dispo sur une ip. En mettre plusieurs en // peut déjà passer ce cap.
Après être un poil agressif sur le timeout TCP peut être utile... Selon l'os...
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Y a que moi ou je suis le seul a voir ce qui hurle... php-cgi ... Pourquoi pas php-fpm ?
On peux faire de bonnes choses avec non ?
Xavier
Liste de diffusion du FRsAG http://www.frsag.org/
Je confirme qu'HAProxy fonctionne très bien :).
Et si vous n'avez pas lu, je conseille http://www.alittlemag.com/effet-capital-m6-comment-tenir-la-charge/(%C3%A9vi..., YMMV).
Le 31 janvier 2014 15:49, Baptiste bedis9@gmail.com a écrit :
HAProxy ne se justifie pas! HAProxy est amour pour les sites à fort traffic ou à forts pics.
Le 21 janv. 2014 à 12:45, seb astien krionux@gmail.com a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre infos@opendoc.net a écrit : Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ? [...]
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
On ne l'a pas encore testé, mais rackspace a une fonction d'auto scaling qu'on souhaite tester. Je suis intéressé par un retour également
http://www.rackspace.com/blog/easily-scale-your-cloud-with-rackspace-auto-sc...
Bonjour,
AWS propose un service d’auto scaling pas trop mal foutu. J’en use et j’en abuse parce qu’il me facilite pas mal la vie pour :
- gérer la montée en charge (entre 2 et X VMs par type de node), avec des seuils d’upscale et downscale (genre « si le CPU est à plus de 90% pendant 5 minutes, ajoute une machine, et recheck 2 minutes plus tard, si il est à moins de 50% pendant 15 minutes tu en retires une et tu checks à nouveau au bout de 5 minutes, et je veux bien deux sucres dans mon thé, merci » ) - m’assurer qu’un nombre fixe d’instance tourne bien, en mode « je dors bien la nuit » : si une machine tombe, elle est immédiatement remplacée - faire les mises à jour de mon infra : une nouvelle AMI avec le code à jour, un nouvel auto scaling group qui me monte toutes les machines dans mes ELB, en les répartissant par AZ. Autant dire du bonheur.
Les trucs intéressants : - on peut changer le « launch group » (donc l’AMI) au sein d’un même groupe d’auto scaling, il faut en revanche tuer les instances une par une pour les remplacer. - le fait de donner une limite haute permet d’éviter d’auto scaler ta facture en cas de passage en première page sur HN. - tu peux brancher ton check d’auto scaling sur le check ELB. C’est vraiment pas mal, parce que si ton appli est en carafe mais que ta machine ping, elle est remplacée quand même. En revanche, si le check échoue parce que ta DB est en carafe, attends toi à du kill / spawn en infinite loop.
Le truc pénible : mon workflow de remplacement lors des mises à jour n’est pas encore parfait.
Hope it helps
On 2014-01-21 13:04, Frederic de Villamil wrote:
Le truc pénible : mon workflow de remplacement lors des mises à jour n’est pas encore parfait. Hope it helps
Mon truc a 2 balles.
Ne pas mettre le "code" sur la machine.
Dans les scripts de demarrage, si /var/www/monsite/index.html n'existe pas, faire git clone de la derniere rev de la branche prod. Et comme tes checks ELB verifient non pas sur / mais sur /index.html, ben ta machine n'entre pas dans le pool avant d'etre "prete".
Tu peux aussi fetcher un script de mise a jour sur S3 en meme temps. Plus besoin de changer d'AMI tous les 4 matins.
Le 21/01/2014 12:38, Alexandre a écrit :
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Hello,
Mon point de vu, en tout cas orienté site de contenu (CMS) :
La réponse la plus efficace est toujours dans une bonne gestion du (des) caches. 1) il n'y a pas plus rapide qu'une requête qui n'est pas faite (réduire les requêtes pour afficher une page, utiliser le cache du navigateur) 2) Il est très rare qu'un donnée doive être recalculée à chaque requête (une page valide 2min me parait convenable, utiliser un cache de page comme varnish et des entêtes HTTP correctes, des cas particuliers comme les commentaires peuvent être traités à part en asynchrone) 3) lorsqu'on construit la page, tout ne doit pas systématiquement provenir d'une base de donnée, le point généralement le plus faible au niveau perfs. utiliser là aussi des caches comme APC (local à une machine), memcache (commun), des systèmes noSQL (redis...)
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle nous a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre infrastructure est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons la possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème. Nous avions pensé à "muscler" notre infra en y ajoutant plus de machines.
[...]
Où passe du temps l'appli ? varnish, apache, base de données ? Il faut d'abord bien cerner le problème pour ensuite agir au bon endroit.
En cas de pic insurmontable, pourquoi est-ce-que ce n'est pas uniquement varnish qui répond, avec des durée d'expiration du cache positionnées assez haute, pour qu'un même client ne revienne pas trop vite. Évidement, si le site doit réellement envoyer des informations différentes à une fréquence élever, il y a des limites, mais calculables.
Pour infos c'est une infra spécifique webservice qui ne renvoie que du json. Cependant pour envoyer la donnée, il y a beaucoup d'url unique. Le double niveau de cache est peu efficace. Pour ce qui est statique c'est un traitement à part.
Alexandre.
On 21/01/14 13:02, Gilles Mocellin wrote:
Le 21/01/2014 12:38, Alexandre a écrit :
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Hello,
Mon point de vu, en tout cas orienté site de contenu (CMS) :
La réponse la plus efficace est toujours dans une bonne gestion du (des) caches.
- il n'y a pas plus rapide qu'une requête qui n'est pas faite (réduire
les requêtes pour afficher une page, utiliser le cache du navigateur) 2) Il est très rare qu'un donnée doive être recalculée à chaque requête (une page valide 2min me parait convenable, utiliser un cache de page comme varnish et des entêtes HTTP correctes, des cas particuliers comme les commentaires peuvent être traités à part en asynchrone) 3) lorsqu'on construit la page, tout ne doit pas systématiquement provenir d'une base de donnée, le point généralement le plus faible au niveau perfs. utiliser là aussi des caches comme APC (local à une machine), memcache (commun), des systèmes noSQL (redis...)
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle nous a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre infrastructure est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons la possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème. Nous avions pensé à "muscler" notre infra en y ajoutant plus de machines.
[...]
Où passe du temps l'appli ? varnish, apache, base de données ? Il faut d'abord bien cerner le problème pour ensuite agir au bon endroit.
En cas de pic insurmontable, pourquoi est-ce-que ce n'est pas uniquement varnish qui répond, avec des durée d'expiration du cache positionnées assez haute, pour qu'un même client ne revienne pas trop vite. Évidement, si le site doit réellement envoyer des informations différentes à une fréquence élever, il y a des limites, mais calculables.
Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
On 21/01/2014 12:38, Alexandre wrote:
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle nous a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre infrastructure est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons la possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème. Nous avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de calcul aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui pourraient être activées sur demande (via une api ?) avec une facturation à l'utilisation.
D'expérience, le problème est souvent lié à des lacunes au niveau de la capacité de l'applicatif à tirer pleinement partie des caches. Typiquement, un varnish en front d'un applicatif qui n'a pas été prévu pour n'apportera (quasiment) rien.
Il est par ailleurs important de bien identifier les bottlenecks. Le pire cas que j'ai vu : une homepage s'écroulant à 30 req/s supportait finalement plus de 4000 simplement en virant le cookie (inutile) qui rendait le cache inopérant. La solution consistant à multiplier les fronts n'étaient clairement pas la bonne ! ;)
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Sinon, le cloud ... quand il s'agit de régler un problème de perfs, bof bof. À moins bien sûr que l'applicatif est été développé en tenant compte des spécificités de ce genre de platformes.
S'il faut vraiment ajouter de la CPU à certains moment _prévisibles_ (saisonniers), j'ai tendance à préférer louer des machines pour l'occasion. Avec un coup de puppet/chef/whatever pour déployer la stack. Et "poubelle" une fois que l'opération est terminée.
Le Tue, Jan 21, 2014 at 12:38:24PM +0100, Alexandre [infos@opendoc.net] a écrit:
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Ça dépend tout d'abord de quel type de web il s'agit.
Si c'est plutot du contenu, des caches bien configurés (CDN, Varnish, cache navigateur, ...) doivent permettre de pousser de gros volumes sans nécessiter des centaines de serveurs.
Pour des choses plus interactives, type applicatif web (webmail, facebook [et encore...], etc.), faut optimiser l'application (là aussi, le cache, ça sert), mais y'a un moment où faut juste scaler horizontalement. Et là, les plate-formes à la AWS et des systèmes de provisioning/déploiement automatisés sont indispensables.
Bonjour Alexandre, Pourquoi as tu arreté akamai ? Si tu as du contenu statique cachable, je peux te proposer un solution CDN à la demande à prix compétitif, utilisable que dans ta période de pointe. Je travaille avec les principaux CDN. Cordialement,
Alexandre writes:
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle nous a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre infrastructure est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons la possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème. Nous avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de calcul aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui pourraient être activées sur demande (via une api ?) avec une facturation à l'utilisation.
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Alexandre. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 21/01/14 15:11, Damien Wetzel wrote:
Bonjour Alexandre, Pourquoi as tu arreté akamai ?
J'ai dit ca ?
Si tu as du contenu statique cachable, je peux te proposer un solution CDN à la demande à prix compétitif, utilisable que dans ta période de pointe. Je travaille avec les principaux CDN.
C'est noté.
Merci.
Cordialement,
Alexandre writes:
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle nous a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre infrastructure est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons la possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème. Nous avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de calcul aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui pourraient être activées sur demande (via une api ?) avec une facturation à l'utilisation.
Ce service doit surement exister chez amazon, gandi, ovh ... L'avez-vous déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Alexandre. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
donc si j'ai bien compris le bottleneck est le traitement PHP, et les caches Memcache ne sont pas une solution. Les accès DB ne sont pas le bottleneck, right ?
Si c'est le cas, à mon avis il faut faire maigrir l'application. Ne pas utiliser de framework lourd type Symfony ou ZF, mais plutôt du micro-framework voir pas de framework du tout. Phalcon ou HHVM sont des solutions alternatives, avec leurs avantages et inconvénients.
Des outils comme le profiler de Xdebug, NewRelic, Apps Dynamics, permettent d'identifier les bottlenecks au sein de l'app php.
Au niveau infra, migrer de CGI à FPM peut aider un peu. NGiNX a une fonctionnalité utile dans ce cas, où il maintient la connexion avec les processes PHP: fastcgi_keep_conn http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
Greg
Le 21 janvier 2014 21:51, Alexandre infos@opendoc.net a écrit :
On 21/01/14 15:11, Damien Wetzel wrote:
Bonjour Alexandre, Pourquoi as tu arreté akamai ?
J'ai dit ca ?
Si tu as du contenu statique cachable, je peux te proposer un solution
CDN à la demande à prix compétitif, utilisable que dans ta période de pointe. Je travaille avec les principaux CDN.
C'est noté.
Merci.
Cordialement,
Alexandre writes:
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous
reposer
la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle
nous
a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre
infrastructure
est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous avons
la
possibilité de désactiver des fonctionnalités à la volée pour soulager le traitement, mais cela reste une façon de contourner le problème.
Nous
avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de
calcul
aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui
pourraient
être activées sur demande (via une api ?) avec une facturation à l'utilisation.
Ce service doit surement exister chez amazon, gandi, ovh ...
L'avez-vous
déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de ce service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Alexandre. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le sujet initiale a été mis de coté par rapport à des questions de performance.... Même optimiser au maximum, a un moment, le scaleout sera la seul solution si la montée en charge est trop forte. L'idée de machine prête à venir en soutien était intérressante...
donc si j'ai bien compris le bottleneck est le traitement PHP, et les
caches Memcache ne sont pas une solution. Les accès DB ne sont pas le bottleneck, right ?
bah non.... Si on reste dans le domaine de l'optimisation des perfs, du cache et d'un site qui répond mieux (sur la même machine), dans ce domaine, on retrouve souvent la phrase suivante (qui a déjà été largement évoqué lors de ce thread)...
"Performance tuning is art not science" ;)
Donc, globalement, il y a certaines "best practices" mais chaque cas est différent et va dépendre du site et de l'application...
Gérer un dimensionnement et la répartition de charge et les perfs qui vont avec, c'est une compétence à part entière qui nécessite des connaissances, de l'analyse, de la réflexion, et une solution adaptée à chaque cas malheureusement ...
Il n'existe pas de "apt-get install sitemarchemieux && /etc/init.d/sitemarchemieux start"... ;)
++
Le 22 janvier 2014 08:43, Greg greg-frsag@duchatelet.net a écrit :
Bonjour,
donc si j'ai bien compris le bottleneck est le traitement PHP, et les caches Memcache ne sont pas une solution. Les accès DB ne sont pas le bottleneck, right ?
Si c'est le cas, à mon avis il faut faire maigrir l'application. Ne pas utiliser de framework lourd type Symfony ou ZF, mais plutôt du micro-framework voir pas de framework du tout. Phalcon ou HHVM sont des solutions alternatives, avec leurs avantages et inconvénients.
Des outils comme le profiler de Xdebug, NewRelic, Apps Dynamics, permettent d'identifier les bottlenecks au sein de l'app php.
Au niveau infra, migrer de CGI à FPM peut aider un peu. NGiNX a une fonctionnalité utile dans ce cas, où il maintient la connexion avec les processes PHP: fastcgi_keep_conn http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
Greg
Le 21 janvier 2014 21:51, Alexandre infos@opendoc.net a écrit :
On 21/01/14 15:11, Damien Wetzel wrote:
Bonjour Alexandre, Pourquoi as tu arreté akamai ?
J'ai dit ca ?
Si tu as du contenu statique cachable, je peux te proposer un solution
CDN à la demande à prix compétitif, utilisable que dans ta période de pointe. Je travaille avec les principaux CDN.
C'est noté.
Merci.
Cordialement,
Alexandre writes:
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous
reposer
la question :
Quelles sont les possibilités pour absorber les montées en charge ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était principalement composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle
nous
a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre
infrastructure
est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous
avons la
possibilité de désactiver des fonctionnalités à la volée pour
soulager
le traitement, mais cela reste une façon de contourner le problème.
Nous
avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de
calcul
aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui
pourraient
être activées sur demande (via une api ?) avec une facturation à l'utilisation.
Ce service doit surement exister chez amazon, gandi, ovh ...
L'avez-vous
déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de
ce
service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Alexandre. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
-
Alexandre -
Baptiste -
Damien Wetzel -
Dominique Rousseau -
Frederic de Villamil -
Gilles Mocellin -
Greg -
Olivier -
Olivier Doucet -
Olivier Grange-Labat -
Pierre `Sn4kY` DOLIDON -
RegisM -
Remi Sandevoir -
seb astien -
Thomas Pedoussaut -
Xavier Beaudouin -
Yohann QUINTON