Configuration serveur requise pour grand site prestashop

Ziham

Est ce que vous avez une idée sur la configuration serveur requise pour une boutique PrestaShop avec 10.000 produits et prés de 10.000 visites par jour ?

Si on devait avoir 3 boutiques de ce genre avec même nombre de produit et même nombre de connexions par jour serait-il judicieux de mettre les trois boutiques dans un même serveur ou doit-ton mettre chaque boutique dans un serveur diffèrent ?

Quel hébergeur pourrait bien satisfaire ce besoin en terme de qualité mais aussi de support technique ?

Faut-il choisir un serveur dédié ou serveur cloud ?

Qu'est ce qui justifie ces choix ?

Merci

doekia

J'imagine que le cloud dont tu parles n'a rien a voir avec la brouette "Cloud PrestaShop", tu parles de cloud au sens Gandi, voire instance S3 elastic d'amazon.

Pour moi ce type de Cloud à un coùt réellement excessif. Par contre dans le cas de besoin massif - j'insiste sur massif - c'est une bonne approche quand il n'existe plus de solution monolitique et que l'on ne souhaites pas se construire de cluster soi-même. D'autant que ce dernier - le cluster - devient de plus en plus difficile compte tenu des forçages de plus en plus présent dans PrestaShop.

10'000 produits n'est pas particulièrement important, maintenant il est important de se mettre d'accord sur la terminologie. Si tes produits sont massivement avec combinaisons, tu dois compter 1 combinaison comme un produit pour ton provisionning. Ne t'inquiète pas trop, des catalogues avec 1M de déclinaisons sont assez bien absorbé en général.
Tu dois tout de même faire attention à la liste d'attributs et groupe d'attributs distinct, surtout si tu envisages d'y greffer la navigation à facette. Les caractéristiques sont aussi un vecteur de surcharge et même constat avec la navigation à facette. Finalement le nombre de langue supportées peut quand à lui rendre l'administration du catalogue coté BO particulièrement lente, non à cause du système mais en raison du volume à faire absorber au navigateur plus quelques autres hérésies de conception.

Il faut également faire attention avec les "cart rules" (bon de réduction) automatiques (sans code), ou impersonelle et à régler correctement l'indexeur de recherche. Le compromis est souvent de mise avec de gros traffic.

10'000 visites, ce n'est pas particulièrement gros - ce serait même bas selon la manière dont tu regardes. Si visites c'est le nombre de pages vues (hors contenu statique) c'est bas. Si visite est le nombre de visiteurs unique tel que google les voit, ça commence à être motivant et si le nombre de page produit distinctes vus hors tout robots ça devient un petit challenge.

En gros, une requête solicite environ 3cpu, l'un sql, l'un php, l'un le net. Ils sont trés loin d''être chargés (env. 2%) mais 3 slices sur 3cpu permet une bonne répartition et donc une réponse optimale. En Quantité Suffisante Pour (QSP),selon les modules en jeu et la complexité de ton PrestaShop il faut compter de 300 à 900ms pour émettre une page. Si on dépasse 900, il y a clairement un souci, par contre 300 c'est quand on bien fait attention à tout. Tous ceux qui annoncent moins, "trichent" et en charge s'écroulent ensuite assez vite.

Si tu charges ton système à 40% ça signifie environ 20 requêtes simultanées pour 3 cpu. Oublie pour l'instant le contenu statique. 10000 visites n'est pas le chiffre que tu dois prendre en considération mais les busts de requêtes auxquels le serveur doit faire face.

Un internaute voit combien de pages en moyenne? Prenons 10. En général le traffic s'étale sur 10h par jour. C'est donc de l'ordre de 1000 visiste par heure en moyenne. 10000 requêtes. Mais si tu as une grosse base facebook, que tu fais un peu de buzz et des campagnes on peut très vite atteindre des pointes à 5000 visites dans l'heure, soit 50000 requêtes.
Ajoute les robots, ajoute les nuisances (tentative de pénétration, ...)

Intéresses toi à ta population. Si tu fais dans le bio par exemple, 90% de tes visites sont depuis un réseau domestique donc bon débit, si tu fais dans la customisation téléphonique ta population sera mobile nomade avec des débits lents (3G, EDGE, GPRS, ... sporadique). Ici le problème est que les resources occupent le système bien au dela de la seconde, ou encore les requêtes sont répétées. Pour palier à la congestion il faut être capable de gérer le double, triple, quadruple de connexions simultanées. Par en terme de CPU réèllement mais en terme mémoire, I/O.

Personellement je ne conseille rien en dessous de machine 8 threads, 32G de mémoire en SSD. Ce genre de bête font très bien le travail https://www.online.net/en/dedicated-server/dedibox-md ça absorbe sans broncher 50 connexions simultanées

Si tu pense avoir besoin de plus ou avoir de la marge de progression, ceci est parfait: https://www.online.net/en/dedicated-server/dedibox-miniwopr ça reste moins de 8€ par jour et avec 32 thread, 196G de mémoire SSD, on couvre un large éventail pour 10 à 100x moins que le coût d'un Cloud.

Si tu pense que ceci est trop faible alors là oui le Cloud c'est la liberté de n'avoir qu'a payer plus pour en avoir plus.

Ziham

Merci beaucoup pour cette réponse détaillée.

Je pense que je vais opter le serveur dédié.

Pour l'instant l'offre de online.net pourrait largement suffire pour répondre aux besoins actuels.

Encore merci, votre réponse m'a vraiment aider à y voir plus claire.

Cordialement

doekia

;-) Pour info, le drapeau c'est pour le signalement (spam, etc...)

Pour voter c'est la coche verte devant la réponse.

Ziham

Merci :-) c'était une erreur de ma part. Je m'en excuse.