Evenementiel sur un site web
Bonjour, Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop. Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04). Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge. Je sais proxyfier intelligemment avec Nginx pour utiliser un cache en ram qui poutre pour tout ce qui est statique. Je sais aussi multiplier les backend pour encaisser une charge plus importante. Ma question actuellement étant de trouver une autre option que de lui monter une infra énorme juste pour un besoin ponctuel. J'insiste sur le fait qu'il VEND sur son site et que du coup, le site génère un cookie à la première page vue, notamment pour gérer le contenu du panier. Est-ce que par hasard vous connaîtriez une solution (je me doute payante) qui sache encaisser de l’événementiel en collant un reverse proxy particulièrement malin devant le site pour n'avoir, par exemple, que les validations commandes qui arrivent sur le backend ? Un truc simple (et magique !) à mettre en œuvre avec juste un changement DNS ou peu plus. Bref, qui tienne dans le délai qu'il nous reste. Merci pour vos lumières ! Julien
Le 5 avril 2017 à 15:00, Julien Escario <escario@azylog.net> a écrit :
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Je sais proxyfier intelligemment avec Nginx pour utiliser un cache en ram qui poutre pour tout ce qui est statique.
Pourquoi tu n'utilises pas tout simplement Cloudfront en tant que CDN
pour tes assets statiques ?
Est-ce que par hasard vous connaîtriez une solution (je me doute payante) qui sache encaisser de l’événementiel en collant un reverse proxy particulièrement malin devant le site pour n'avoir, par exemple, que les validations commandes qui arrivent sur le backend ?
HaProxy te fait ça très bien, tu peux te débrouiller pour créer un backend uniquement -ou pas- dédié à tes validations commandes. -- Cyril Beaufrere
Salut, Avec prestashop je serais curieux de voir les réponses aussi. Pour Magento on arrive à faire un truc pas mal avec turpentine pour coller un varnish devant, tous les modules n'aprécient pas forcément out of the box mais sinon c'est pas mal du tout. Pour Prestashop par contre je n'ai encore rien trouvé de similaire malheureusement .. On Wed, Apr 05, 2017 at 03:00:18PM +0200, Julien Escario wrote:
Bonjour, Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Je sais proxyfier intelligemment avec Nginx pour utiliser un cache en ram qui poutre pour tout ce qui est statique.
Je sais aussi multiplier les backend pour encaisser une charge plus importante.
Ma question actuellement étant de trouver une autre option que de lui monter une infra énorme juste pour un besoin ponctuel.
J'insiste sur le fait qu'il VEND sur son site et que du coup, le site génère un cookie à la première page vue, notamment pour gérer le contenu du panier.
Est-ce que par hasard vous connaîtriez une solution (je me doute payante) qui sache encaisser de l’événementiel en collant un reverse proxy particulièrement malin devant le site pour n'avoir, par exemple, que les validations commandes qui arrivent sur le backend ? Un truc simple (et magique !) à mettre en œuvre avec juste un changement DNS ou peu plus. Bref, qui tienne dans le délai qu'il nous reste.
Merci pour vos lumières ! Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Tu peux pas facilement mettre tout ça dans AWS par exemple, pour instancier autant de serveurs front-end que nécessaire et augmenter les perfs du backend pour suivre ? Sinon, je doute qu’un CDN puisse gérer la partie dynamique/panier/cookies/paiement, mais l’idée d’un CDN dans ce cas n’est-elle pas de décharger les serveurs de tout ce qui est statique (photos etc…) pour qu’ils n’aient plus que la valeur ajoutée à gérer ? Tu peux facilement faire une maquette avec Cloudflare par exemple, qui est simple à déployer et abordable, et voir combien la plateforme de ton client peut absorber de commandes par heure une fois délestée du tout venant.
Le 5 avr. 2017 à 15:00, Julien Escario <escario@azylog.net> a écrit :
Bonjour, Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Je sais proxyfier intelligemment avec Nginx pour utiliser un cache en ram qui poutre pour tout ce qui est statique.
Je sais aussi multiplier les backend pour encaisser une charge plus importante.
Ma question actuellement étant de trouver une autre option que de lui monter une infra énorme juste pour un besoin ponctuel.
J'insiste sur le fait qu'il VEND sur son site et que du coup, le site génère un cookie à la première page vue, notamment pour gérer le contenu du panier.
Est-ce que par hasard vous connaîtriez une solution (je me doute payante) qui sache encaisser de l’événementiel en collant un reverse proxy particulièrement malin devant le site pour n'avoir, par exemple, que les validations commandes qui arrivent sur le backend ? Un truc simple (et magique !) à mettre en œuvre avec juste un changement DNS ou peu plus. Bref, qui tienne dans le délai qu'il nous reste.
Merci pour vos lumières ! Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 05/04/2017 à 15:25, David Ponzone a écrit :
Tu peux pas facilement mettre tout ça dans AWS par exemple, pour instancier autant de serveurs front-end que nécessaire et augmenter les perfs du backend pour suivre ?
Le front-end devrait suivre. On a des expériences similaires avec du site vitrine qu'on a mis intégralement en cache et ça soutient plusieurs milliers de req/s avec moins de 0.5 de load. Pour les backend, j'ai l'infra qui va bien pour en mettre un bon paquet sans avoir besoin d'aller chez EC2. Bon, certes, on ne fait pas l'autoscaling mais on sait en rajouter plusieurs dizaines très rapidement (< 1h). Je cherche une autre option que de multiplier les VMs.
Sinon, je doute qu’un CDN puisse gérer la partie dynamique/panier/cookies/paiement, mais l’idée d’un CDN dans ce cas n’est-elle pas de décharger les serveurs de tout ce qui est statique (photos etc…) pour qu’ils n’aient plus que la valeur ajoutée à gérer ?
Oui, j'ai parlé de CDN abusivement. On est bien d'accord que la valeur ajoutée d'un CDN, c'est l'anycast sur le statique, pas la tenue en charge.
Tu peux facilement faire une maquette avec Cloudflare par exemple, qui est simple à déployer et abordable, et voir combien la plateforme de ton client peut absorber de commandes par heure une fois délestée du tout venant.
Ben ça, j'ai déjà le chiffre : avec deux backends, un MariaDB et un reverse proxy et après optimisation rapide du tout, je tiens 50 req/s. Le MariaDB se touche un peu donc j'imagine qu'en multipliant les backends, je peux pousser encore pas mal (~ x4). Le gros de la base Prestashop est InnoDB d'où le choix de MariaDB pour avoir XtraDB. J'avoue que ça change bien les choses pour avoir testé les deux aujourd'hui. Julien
Passer l'index en .html, pour les soucis de cookie ou autre, t'auras pas trop le choix. Avec nginx (ou haproxy), créer une règle : si "pas encore venu sur le site, présenter l'index.html, sinon le vrai .php", je ne saurais le faire avec nginx. (Ca pourrait aussi se faire en PHP) Mettre tout ton statique sur un autre serveur, voir même du mutualisé. T'as un peu de temps pour voir venir quand même, mais généralement pour ce type d'évent, de mon expérience, les internautes vont aller voir, si la home est un peu lente, ils iront pas plus loin. Donc coder une landing page assez simple d'ici lundi avec des liens vers les bons articles. Bon courage, et n'hésites pas à nous faire un retour sur comment ça a été et ce que tu as prit comme solution. Le 05/04/2017 à 15:00, Julien Escario a écrit :
Bonjour, Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Je sais proxyfier intelligemment avec Nginx pour utiliser un cache en ram qui poutre pour tout ce qui est statique.
Je sais aussi multiplier les backend pour encaisser une charge plus importante.
Ma question actuellement étant de trouver une autre option que de lui monter une infra énorme juste pour un besoin ponctuel.
J'insiste sur le fait qu'il VEND sur son site et que du coup, le site génère un cookie à la première page vue, notamment pour gérer le contenu du panier.
Est-ce que par hasard vous connaîtriez une solution (je me doute payante) qui sache encaisser de l’événementiel en collant un reverse proxy particulièrement malin devant le site pour n'avoir, par exemple, que les validations commandes qui arrivent sur le backend ? Un truc simple (et magique !) à mettre en œuvre avec juste un changement DNS ou peu plus. Bref, qui tienne dans le délai qu'il nous reste.
Merci pour vos lumières ! Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 05/04/2017 à 15:54, Boris Pigeot a écrit :
Passer l'index en .html, pour les soucis de cookie ou autre, t'auras pas trop le choix.
Avec nginx (ou haproxy), créer une règle : si "pas encore venu sur le site, présenter l'index.html, sinon le vrai .php", je ne saurais le faire avec nginx. (Ca pourrait aussi se faire en PHP)
Ah chouette idée ça ! Je pensais leur proposer de créer une landing page genre 'cliquez ici pour rentrer sur le site' mais ça fait vieillot et ça va leur faire fuir du trafic. Du coup, tu viens de me donner une possibilité intermédiaire, merci !
Mettre tout ton statique sur un autre serveur, voir même du mutualisé.
Encore une fois, ce n'est pas le statique qui me tracasse.
T'as un peu de temps pour voir venir quand même, mais généralement pour ce type d'évent, de mon expérience, les internautes vont aller voir, si la home est un peu lente, ils iront pas plus loin.
Oui, clairement.
Donc coder une landing page assez simple d'ici lundi avec des liens vers les bons articles.
Bon courage, et n'hésites pas à nous faire un retour sur comment ça a été et ce que tu as prit comme solution.
Ben ca dépend aussi de ce que le client est prêt à mettre hein. Parce qu'il fuit déjà quand je parle de 1500 € de setup pour tout ça. Comme un con, avec la deadline et comme je n'aime pas bosser en urgence le week-end, j'ai déjà fait les 3/4 du taf. Julien
Le 5 avril 2017 à 15:00, Julien Escario <escario@azylog.net> a écrit :
Bonjour,
Salut,
Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Bienvenue au club des gens dont les clients leur annonce au détour d'une conversation qu'ils passent à la TV dans moins d'une semaine :D
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Alors, j'ai vécu ça avec plusieurs clients. Si le site n'est pas optimisé, y'a pas de magie : va falloir cacher à mort. Surtout que, AFAIK, PrestaShop n'aime pas Varnish. Pour un client qui est passé sur Capital, j'ai appliqué la méthode A Little Market dont le lien a été posté précédemment : on passe le site en read-only, on configure Varnish pour virer les cookies et tout cacher. Vraiment tout. Si un client fait une action qui demande du "write" (ajout panier, login...), on affiche une jolie landing page disant "Désolé, trop de connexions, veuillez nous laisser votre email si vous souhaitez être recontacté quand le site ira mieux". Résultat, le site n'a pas planté et on a récolté pleins d'emails qu'on a répartis sur plusieurs mailings dans les jours suivants. Sinon tu peux toujours essayer d'ajouter X serveurs en backend pour garder le site pleinement fonctionnel, mais franchement c'est risqué. -- Jonathan Leroy.
Le 05/04/2017 à 16:15, Jonathan Leroy a écrit :
Le 5 avril 2017 à 15:00, Julien Escario <escario@azylog.net> a écrit :
Bonjour,
Salut,
Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Bienvenue au club des gens dont les clients leur annonce au détour d'une conversation qu'ils passent à la TV dans moins d'une semaine :D
Ah ben pour le coup, non ! Ils m'ont prévenu environ un mois avant, c'est correct. Le truc c'est qu'ils veulent les soussous des visites mais pas l'infra qui permet de le faire. Et ça, c'est maintenant ;-) Chuis pas chiant en plus, j'offre l'infra (des hyperviseurs qui ne foutent rien, on en a 2/3 et le challenge est sympa).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Alors, j'ai vécu ça avec plusieurs clients. Si le site n'est pas optimisé, y'a pas de magie : va falloir cacher à mort. Surtout que, AFAIK, PrestaShop n'aime pas Varnish.
Pour un client qui est passé sur Capital, j'ai appliqué la méthode A Little Market dont le lien a été posté précédemment : on passe le site en read-only, on configure Varnish pour virer les cookies et tout cacher. Vraiment tout.
Si un client fait une action qui demande du "write" (ajout panier, login...), on affiche une jolie landing page disant "Désolé, trop de connexions, veuillez nous laisser votre email si vous souhaitez être recontacté quand le site ira mieux".
Mouarf, c'est pas mal ça. Ca prend 15 minutes de conf et basta ;-) On le fait pour un autre client mais son site ne pause aucune difficulté à être totalement statique. Un bon cache TOTAL avec TTL à 1h, fini. J'aurais aimé leur proposer mieux mais si ils ne veulent pas de débloquer de budget là dessus, ça va finir comme ça, oui.
Résultat, le site n'a pas planté et on a récolté pleins d'emails qu'on a répartis sur plusieurs mailings dans les jours suivants.
Sinon tu peux toujours essayer d'ajouter X serveurs en backend pour garder le site pleinement fonctionnel, mais franchement c'est risqué.
Le challenge est sympa ;-) Il faut juste prévoir la page de maintenance 'au cas où' (c)2017. X étant un entier compris entre 2 et 500 en gros. Facile. Plus sérieusement, le Mariadb va mourir avant de toute façon et on a pas le temps pour faire du master/slave avec modif de prestashop pour différencier les lectures des écritures. Julien
Le 2017-04-05 16:25, Julien Escario a écrit : Salut,
Plus sérieusement, le Mariadb va mourir avant de toute façon et on a pas le temps pour faire du master/slave avec modif de prestashop pour différencier les lectures des écritures.
Julien
La mise en place de Galera cluster + haproxy + keepalived ne serait pas envisageable? Çà évite de gérer la notion de Master/Slave sur ton prestashop? -- Cordialement, Maxime Batouche
La mise en place de Galera cluster + haproxy + keepalived ne serait pas envisageable? Çà évite de gérer la notion de Master/Slave sur ton prestashop?
Ça, ou un bête ProxySQL en frontal pour faire la différenciation des lectures / écritures "de force" sans demander l'avis de Prestashop.
Re, Sur ce point, tu peux aller jeter un oeil dans la classe DB de PS (1.6, pas encore lu la 1.7), et on y decouvre que PS sait gerer un master pour les ecritures et des slaves pour la lecture. Bon, par contre c'est gravement soumis a lz quzlite du code du theme et des modules installes... Envoyé de mon iPhone Le 5 avr. 2017 à 16:40, lemonnierk@ulrar.net a écrit :
La mise en place de Galera cluster + haproxy + keepalived ne serait pas envisageable? Çà évite de gérer la notion de Master/Slave sur ton prestashop?
Ça, ou un bête ProxySQL en frontal pour faire la différenciation des lectures / écritures "de force" sans demander l'avis de Prestashop. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Wed, Apr 05, 2017 at 04:25:54PM +0200, Julien Escario [escario@azylog.net] a écrit: [...]
Un bon cache TOTAL avec TTL à 1h, fini. J'aurais aimé leur proposer mieux mais si ils ne veulent pas de débloquer de budget là dessus, ça va finir comme ça, oui.
Avec une conf violente qui cache sans cooperation du CMS, tu peux mettre moins d'1h, ca permet au client qui veut quand meme pouvoir faire des modifs (si si :)) de les faire. En mode pompier sans budget, c'est de toute façon à peu près la seule façon de "tenir" (= repondre aux requetes, et autre chose que 500) Pour des sites e-commerce, je sais pas quel est le pourcentage de "transformation" sur un passage télé, mais des cas que j'ai croisé sur d'autres contenus, c'est relativement faible le nombre de visiteurs qui font plus qu'afficher la home du site ('fin le lien le mieux référencé dans Google :o))... -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Plop! Petit cheveu sur la soupe :) Ton PS devrait etre capable de gerer ~1000 users dans la meme minutes sans pbs, je l'eu fait pour les soldes de janvier cette annee. Ton nginx peut gerer du cache fpm (oui, pas de reverse pour raison de cookies) sur certains type de page (ie tout sauf tunnel de commande, mon compte, et les pages produits si gestion de quantite) Le point vital a surveiller est en fait l'affichage du panier/mon compte: si ton client accepte de degager le cote dynamique, colle tout ca en cache. Dans le cas contraire, il "suffit" de modifier le theme pour recevoir ces infos en POST (30 mins de dev, 1 journee d'inté) Et la, Ô miracle, analytics peut voir 1000 "clients en simultanee sur un bi-4-cores 32gb de ram (et un backend mariadb que tu as deja, donc de ce cote ca roule) Pense bien a coller un max de cache en tmpfs. Feinte "supplementaire": un reverse proxy sur apache sur une autre ip pour un pseudo cdn en tmpfs Desole du manque d'accents, les gsm, c'est pas le pied.. a ta dispo pour en pzrler plus en details si besoin ;) Envoyé de mon iPhone
Le 5 avr. 2017 à 16:25, Julien Escario <escario@azylog.net> a écrit :
Le 05/04/2017 à 16:15, Jonathan Leroy a écrit : Le 5 avril 2017 à 15:00, Julien Escario <escario@azylog.net> a écrit : Bonjour,
Salut,
Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Bienvenue au club des gens dont les clients leur annonce au détour d'une conversation qu'ils passent à la TV dans moins d'une semaine :D
Ah ben pour le coup, non ! Ils m'ont prévenu environ un mois avant, c'est correct. Le truc c'est qu'ils veulent les soussous des visites mais pas l'infra qui permet de le faire. Et ça, c'est maintenant ;-)
Chuis pas chiant en plus, j'offre l'infra (des hyperviseurs qui ne foutent rien, on en a 2/3 et le challenge est sympa).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Alors, j'ai vécu ça avec plusieurs clients. Si le site n'est pas optimisé, y'a pas de magie : va falloir cacher à mort. Surtout que, AFAIK, PrestaShop n'aime pas Varnish.
Pour un client qui est passé sur Capital, j'ai appliqué la méthode A Little Market dont le lien a été posté précédemment : on passe le site en read-only, on configure Varnish pour virer les cookies et tout cacher. Vraiment tout.
Si un client fait une action qui demande du "write" (ajout panier, login...), on affiche une jolie landing page disant "Désolé, trop de connexions, veuillez nous laisser votre email si vous souhaitez être recontacté quand le site ira mieux".
Mouarf, c'est pas mal ça. Ca prend 15 minutes de conf et basta ;-) On le fait pour un autre client mais son site ne pause aucune difficulté à être totalement statique.
Un bon cache TOTAL avec TTL à 1h, fini. J'aurais aimé leur proposer mieux mais si ils ne veulent pas de débloquer de budget là dessus, ça va finir comme ça, oui.
Résultat, le site n'a pas planté et on a récolté pleins d'emails qu'on a répartis sur plusieurs mailings dans les jours suivants.
Sinon tu peux toujours essayer d'ajouter X serveurs en backend pour garder le site pleinement fonctionnel, mais franchement c'est risqué.
Le challenge est sympa ;-) Il faut juste prévoir la page de maintenance 'au cas où' (c)2017.
X étant un entier compris entre 2 et 500 en gros. Facile.
Plus sérieusement, le Mariadb va mourir avant de toute façon et on a pas le temps pour faire du master/slave avec modif de prestashop pour différencier les lectures des écritures.
Julien
Le 05/04/2017 à 16:47, Lifo a écrit :
Plop!
Petit cheveu sur la soupe :) Ton PS devrait etre capable de gerer ~1000 users dans la meme minutes sans pbs, je l'eu fait pour les soldes de janvier cette annee.
Ton nginx peut gerer du cache fpm (oui, pas de reverse pour raison de cookies) sur certains type de page (ie tout sauf tunnel de commande, mon compte, et les pages produits si gestion de quantite)
Le point vital a surveiller est en fait l'affichage du panier/mon compte: si ton client accepte de degager le cote dynamique, colle tout ca en cache. Dans le cas contraire, il "suffit" de modifier le theme pour recevoir ces infos en POST (30 mins de dev, 1 journee d'inté)
Et la, Ô miracle, analytics peut voir 1000 "clients en simultanee sur un bi-4-cores 32gb de ram (et un backend mariadb que tu as deja, donc de ce cote ca roule)
Pense bien a coller un max de cache en tmpfs.
Feinte "supplementaire": un reverse proxy sur apache sur une autre ip pour un pseudo cdn en tmpfs
Desole du manque d'accents, les gsm, c'est pas le pied.. a ta dispo pour en pzrler plus en details si besoin ;)
Merci ! Pas mal de pistes très précises dans ta réponse. Pour le moment, je fais statu-quo en attendant de voir ce que mon client veut faire mais je me garde ça dans un coin, notamment sur la partie directe nginx -> fpm pour faire du cache, je n'y avais pas pensé. Après, il faut voir si avec l'opcode Zend de PHP7, le gain est encore significatif. Pas sûr ... Julien
Re,
Merci ! Pas mal de pistes très précises dans ta réponse.
Pour le moment, je fais statu-quo en attendant de voir ce que mon client veut faire mais je me garde ça dans un coin, notamment sur la partie directe nginx -> fpm pour faire du cache, je n'y avais pas pensé. Après, il faut voir si avec l'opcode Zend de PHP7, le gain est encore significatif. Pas sûr ...
Si :) Pour la bonne et simple raison que le cache FPM génère de l'HTML et que l'HTML sera toujours plus rapide que du php à interpreter ;) La conf Nginx/PS est relativement simple, et en prime tu économise réellement tous les "opendir" de ton "allowoverride" ;) @++ et bon courage !
Le 05/04/2017 à 15:00, Julien Escario a écrit :
Bonjour, Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Pour des besoins ponctuels et un délai aussi court, pourquoi ne pas s'appuyer sur Cloudflare ? Même s'ils ont un peu défrayé la chronique il y a peu, cela peut être pratique comme service. Mes 2 cents, Nicolas
+1 pour Cloudflare. Et prévoir une page d'urgence en pur HTML avec un message "Notre site est surchargé" et un formulaire externe (type mailchimp) pour récolter les mails. 2017-04-05 23:34 GMT+02:00 Nicolas Steinmetz <public+frsag@steinmetz.fr>:
Le 05/04/2017 à 15:00, Julien Escario a écrit :
Bonjour, Un de nos clients va 'passer à la télé'. Aujourd'hui, il a une petite boutique basée sur Prestashop.
Son infra actuelle n'est évidemment pas du tout adaptée à la masse de trafic qu'il se prendre sur la tronche lundi soir (oui, oui, le 10/04).
Au delà des milles et une petites optimisation possibles pour prestashop, je cherche une solution type CDN qui permette d'encaisser la charge.
Pour des besoins ponctuels et un délai aussi court, pourquoi ne pas s'appuyer sur Cloudflare ?
Même s'ils ont un peu défrayé la chronique il y a peu, cela peut être pratique comme service.
Mes 2 cents, Nicolas
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Je peux vous affirmé que Cloudflare c'est pas un miracle non plus. Je prend mon exemple, je gère actuellement le serveur https://despair-paradise.com/, suite à des article très bien référencer dans google, on a eux un pic de +60 000 visiteur unique en 1 journée, et bas même avec Cloudflare c'est tomber (page qui mettais plus de 20 seconde montre en main pour marcher, quand ça marchais, du coup les users mass F5 ... tu peux imaginer la suite) . Go plutôt sur une solution avec Haproxy (quitte à prendre du https://www.scaleway.com/ pour avoir des serveurs en plusau moment des pic) ou voir des boites comme https://www.clever-cloud.com qui on déjà eu des boite qui on vu leur trafique explosé suite a des passage à la TV. Cordialement.
participants (14)
-
Arthur Mayrand -
Boris Pigeot -
Cyril Beaufrere -
David Ponzone -
Dominique Rousseau -
Jonathan Leroy -
Julien Escario -
lemonnierk＠ulrar.net -
Lifo -
Maxime Batouche -
merlin8282 -
Nicolas collignon -
Nicolas Steinmetz -
Sébastien COUREAU