Bonjour à toutes et à tous,
J'ai deux instances :
B2-120 : pour apache 2 avec un site prestashop 1.7 et un
R2-240 : pour mariadb ( uniquement ce service)
Le site rencontre en moment de promotions de gros pics de visiteurs ( +1000 simultanés) et à arrivé à un certain nombre de visiteur, le site bug, j'ai des timeout alors que aucun des deux serveurs n'est saturé en perf.
Pas de slow Queries dans maria DB.
La DB fait +/- 20GO avec 200 000 000 d'enregistrements
Les deux instances sont dans le même datacenter ( GRA11).
Ma première idée été de les mettre dans le Vrack afin d'avoir un trafic "local" pour la communication avec la DB… ça marche mais plus lent que de passer par l'ip publique… J'ai donc utilisé la bande passante publique pour communiquer avec la DB.
Apres cela, le site a commencer à aller mieux, mais nous avons encore des bugs et timeout.
En période de pique de connections j'ai +/- 200 mbps de bande passante d'utilisé entre le site et la db.
J'ai déjà optimisé mariaDB afin d'optimiser les perfs.
J'ai un cloudflare (gratuit) sur le site.
En période de pique j'ai +/- 1 commande toutes les 3 secondes
En période "normale" le site fonctionne très bien.
Auriez vous une idée de comment améliorer la situation en cas de pique de visite ?
(Auparavant j'avais que le B2-120 pour les deux services… c'était encore pire, car quand mariadb surcharge, apache se mettait a être surchargé aussi à cause d'un manque de ressources.
Merci pour votre aide ou vos avis
Compliqué…
Il y a des mécanismes de cache possible côté PrestaShop ? Je présume qu'ils sont en place…
Il peut être possible de mettre un "slave" mariadb sur le serveur web, et de "taper" sur le slave local pour les query en select… Je ne sais pas si prestashop l'intègre, sinon il faut passer par quelque chose comme proxysql qui lui fera le split entre les query SELECT et les autres.
ProxySQL permet également de mettre des requêtes en cache, mais ça demande un gros boulot d'audit pour déterminer ce qui peut être mis en cache ou pas…
Ou alors un cluster mariadb pour répartir la charge, mais là ça va rajouter des coûts et de la complexité. D'autant + que les requêtes INSERT / UPDATE / DELETE doivent être synchronisées dans tout le cluster pour être "validée". Et il faudra un loadbalancer pour répartir les requêtes entre les instances sql.
Le gros soucis avec une boutique c'est que les caches sont compliqués à utiliser, sauf si prévu dans le "code" du site, pour pouvoir gérer un cache applicatif pour les utilisateurs authentifiés…
Si j'ai bien suivi, le point de blocage serait entre le serveur web et la bdd ? La bande passante est suffisante ? On est sur du 10Gb/s, ça va être difficile de faire mieux en PCI.
Et quid de la charge des 2 serveurs ? Un gros baremetal qui aurait tt en local avec disques nvme pourrait faire le job ? Reste le risque de problèmes hardware sur le baremetal… Quel est la conso ram / cpu sur les instances ?
Quelque chose du genre adv6 avec 256Go de RAM (voir 512 ?) pourrait faire le job peut être… Et au moins pas de soucis de bande passante entre le site et le sgbd, et disques nvme également, et cpu + performant.
C'est difficile de donner des conseils comme ça sans avoir toutes les datas…
Tout va dépendre aussi des compétences techniques, à la fois en admin sys et sur prestashop…
Le baremetal est une idée à tester (sur 1 mois ?), sinon l'étape d'après c'est le cluster… Avec plusieurs front web et un cluster mariadb, pour répartir le boulot…
Mais ça fait coûteux uniquement pour des pics d'activité (encore que ça se calcul avec le CA généré pendant les pics)…
Sinon un concurrent Suisse a des offres auto scalables et infôgérée, je n'ai jamais mis ça en prod donc pas vraiment de retour…
En tt cas je suis intéressé par les solutions qui seraient éventuellement mises en oeuvre pour améliorer les choses.
Comme @Sich je conseillerai un gros serveur physique avec tout en local.
A puissance comparé, le physique coûte bien moins cher que le cloud.
Au niveau des caches si tu peux utiliser Memcached ça peut être un gros plus mais peut aussi nécessiter un peu de travail sur certain template.
Sur l'instance Apache tu as essayé mod_cache ? ou mod_cache_disk ?
Merci a vous deux pour la réponse,
En cas de pique , le apache tourne à 5% de cpu et 20% de ram et le mysql 30% de cpu et 50% de ram , point de vue bande passante max 200 MB/S.
Quand les deux instantance communiquent par le vrack, on est apparement limité à 100mbps. j'ai donc changé et passer par l'ip publique et la moins de soucis , en période de pique ça n'a pas saturé au point de vue BP.
Après, je suspecte aussi que prestashop aie quelques requette qui ne sont pas optimisée …
Je vais aussi conseiller de migrer le presta 1.7 vers le 1.8, il doit y certainement des optimisations de la bdd entre les deux versions
Je vous tiens au courant pour la suite
Merci
@Sich, l'idée du proxy sql m'a déjà traversé l'esprit mais déconseillé par le support prestashop … memcached déja installé et config dans le serveur web.
Je pense que vais suivre votre conseil et partir sur un adv-6 avec 256go pour commencer et au besoin augmenter.
Bonjour,
Quand les deux instantance communiquent par le vrack, on est apparement limité à 100mbps.
non d'après les specs des instance vous pouvez faire du 4 Gbit/s max (b2-120 & r2-240).
Par contre, pourquoi prendre des instances aussi "démesuré" ?
Car au cumul cela vous fait 48vCPU / 360Go de RAM & 800Go de SSD (stockage réseau) pour un coût mensuel de 572€ (HT).
Perso je partirais sur 2x Advance-5 (RBX & GRA) en 256Go le tout en virtualisant les machines (cela va engendrer 18% d’augmentation mensuel 572€ -> 688€/HT/mois mais gagner en redondance si jamais vous n'aviez pas de PRA/PCA de prévu).
Pourquoi 2 serveurs :
Dans un premier temps cela permet d'avoir un serveur de PRA le temps de voir si un seul serveur arrive à encaisser la charge (normalement oui).
Ensuite si jamais un seul serveur ne nouveau pas, cela permet de séparer le web & SQL sur 2 serveurs différents, tout en pouvant faire une réplication pour transformer un serveur en PRA rapidement.
De plus de bases, ces serveurs ont un vrack à 2Gbit/s garanti ce qui devrait être plus performant (en théorie) que de passer par la partie publique (et c'est facile à tester au besoin).
Maintenant le côté négatif de faire cela est que :
Cela va vous faire 2 serveurs à manager et monitorer (comme avec vos 2 instances, mais en plus faut bien monitorer la partie hardware).
Cela va vous couter du temps pour faire la migration
Vous serez bloqué d'un point de vue ressources vu que ce n’est pas possible de faire d'upgrade hardware (mais si c'est bien pris en compte et calculé, cela ne va pas trop déranger).
Enfin vous devez vous demander pourquoi faire de la virtualisation pour 2 voir 1 VM ?
Simple, cela permet d'avoir une gestion plus simple des ressources au prix de quelques % de performance brute de perdu.
Par gestion plus simple, j’entends :
- Plus facile à bouger une VM que des datas/service installées en "hard"
- Plus facile à sauvegarder (on peut coupler script pour avoir un dump cohérent + sauvegarde de la VM en elle-même).
- Plus facile pour créer une infra avec des redondances/sécurité (genre l'exemple du PRA).
- Plus facile si jamais on souhaite faire des tests et/ou préparer une migration de services/version (genre passage de Deb11 à Deb12).
Sinon je rejoins @Sich& @TTY, là un serveur physique avec des ressources locales et maitrisées à 100% est mieux sur le papier que 2 instances PCI (déjà passer de SSD réseaux à NVMe local cela va aider sur la partie BDD).
Cordialement, janus57
Je pense que vais suivre votre conseil et partir sur un adv-6 avec 256go pour commencer et au besoin augmenter.
Attention, les baremetals ne sont pas "upgradables".
Donc soit à les prendre sans engagement et à tout migrer on est "coincé" sur la config en cours.
Perso je partirais sur 2x Advance-5 (RBX & GRA) en 256Go le tout en virtualisant les machines
Avec une réplication proxmox pour pouvoir remonter rapidement la vm ? A voir la rentabilité du truc, tt va dépendre du CA de la boutique.
Tu me diras avec 1 commande toutes les 3s le downtime doit commencer à coûter pas mal en perte de CA.
Et éventuellement on peut faire 2 1/2 vm, avec 1 vm en prod sur chaque serveur pour ne pas avoir un serveur qui ne "sert à rien", mais là il faut surveiller la bande passante.
Tu as des retours d'expérience avec ce genre de réplication et la "consistance" des bdds ?
Bonjour,
Avec une réplication proxmox pour pouvoir remonter rapidement la vm ?
Oui, car la en PCI concrètement si la VM est down elle est down jusqu'à ce que OVH répare l'hôte ou alors un PRA est enclenché.
A voir la rentabilité du truc, tt va dépendre du CA de la boutique.
Vu ce qui est dit dans le topic de départ, je pense quand même que le budget IT à été calculé en fonction de ce que rapporte le site et surtout de prendre en compte que si demain le site est mort (genre totalement effacé) quel solution ont été mises en place pour prévenir ce scénario catastrophe.
Tu as des retours d'expérience avec ce genre de réplication et la "consistance" des bdds ?
Non car là où je travaille on utilise CEPH avec le cluster qui est répartis sur 2 site géographique donc les DATA sont sur les 2 sites.
Par contre ont utilise la sauvegarde de proxmox avec l'agent QEMU qui est censé garantir l'intégrité des donnés et jusqu'à maintenant on a eu 0 problèmes lors de restauration (après on a pas spécialement forcé pour vérifier si on arrivez à corrompre une BDD ou pas).
Cordialement, janus57