Performances de prestashop pour un site à fort traffic. (Serveur dédié)

[jsmith]

Bonjour,
J'aimerais savoir si Prestashop est adapté pour faire tourner une boutique en ligne dont le traffic en ligne serait important. Entre 10,000 et 100,000 visiteurs par jour. Même si le site n'aura pas forcément une telle audience au début, il est bon de savoir qu'il demeure "scalable", (évolutif). Que ce soit en terme de performance en charge, ou en ajout de produits/catégories.
Le site comprendrait 15,000 catégories différentes, pour un nombre de produits de 4,000 à 20,000.
Est-il envisageable d'utiliser Prestashop pour une telle boutique?


Aussi, est-il possible d'optimiser Prestashop pour un fonctionnement rapide ? (<200 ms/page) (temps de génération de la page) Si oui, comment ? Peut-on mettre la totalité du site dans un cache, ou la base de donnée?

Ou dois-je me tourner vers opencart dont les performances sont bien plus élevées en charge? (temps moyen de chargement d'après mes tests <100 ms dans tous les cas, avec 10,000 cat / 4000 produits)

J'hésite bcp entre opencart et prestashop. L'unique point pour opencart est la performance au long terme. Il y a beaucoup de fonctions qui restent à développer (trop pe), mais il est facile de coder car leur système MVC est très intuitif, bcp plus que prestashop.


Il m'est très important de le savoir avant de commencer à développer car après, il est trop tard, changer de plate-forme serait une perte de temps énorme.

Je précise que le site tournerait sur un serveur dédié, 4 coeurs (Q6600 ou corei5), 4-8 go de ram.


Pour ceux qui pensent que la rapidité n'est pas un point importante : (tout comme les admins de opencart, tellement sûrs d'eux quand ils affirment que les urls SEO ne servent à rien..... Rhaa bf)

La rapidité d'un site internet est un point CENTRAL. Les gens détestent attendre, et ce de plus en plus. Ils n'hésiteront pas à quitter votre site pour peu qu'ils attendent une seconde de trop.
Pourquoi ? Parce que multipliée par le nombre de pages vues, cette seconde peut se transformer en minutes, et laisser place à un fort sentiment d'impatience. Résultat pour 75% des gens (étude à l'appui) : -> on zappe et directi google chez le concurrent.

[jeckyl]

Salut,

Je vais juste réagir sans vraiment répondre.

Concernant la rapidité jes usi toujours à me battre pour que les créateur, comprenne premièrement que tout le monde n'est pas avec une connexion adsl 20Mbits. Donc la conception du site et de sa structure est primordiale.

Par contre tu aborde 2 ou 3 point qui m'étonnent.
Tu annonce de l'ordre de 20 000 produits dans 15 000 catégories, donc ma première réaction est de chercher qu'elle activité peut provoquer ce type de structure, et je n'ai pas trouvé. Pas vraiment grave en soit.

Par contre ma réaction est plus mitigé qu'en à l'utilisation d'une plateforme opensource pour un site de cette ampleur, qui va donc, à moyen terme générer des millions d'euros de CA mensuel (1% de 100 000 visiteur = 1 000 x 20€ de panier moyen = 20 000 € jours x 30 = 600 000€), oups, pas des millions. Donc j'ai du mal à comprendre pourquoi ne pas faire du fromscratch et ainsi avoir exactement ce qu'il vous faut et rien en trop qui ferait ralentir la machine ???

Voilà ce n'est que mon interprétation de ton message car je ne suis pas assez performant sur le load balancing et le cloud computing pour gérer des sites de cette envergure.

[jsmith]

J'ai fait une erreur, je voulais dire visites et non visiteurs... Ca change tout, un même visiteur pouvant consulter plusieurs pages lors de sa visite. Le nombre de visiteurs réels est donc plutôt entre 1000 et 10,000.
Bien que le nombre de catégories sera probablement inférieur, certains sites utilisent quasiment une catégorie par type de produit. (Comme les consommables : http://www.francetoner.fr/, autant de catégories que de références) et donc, autant de produits. (Dans leur cas > 100,000 apparemment)
Ce n'est pas tant le poids de la page qui pose problème (donc ce n'est pas un pb de connexion haut débit chez le client),
mais le temps de génération de la page côté serveur, qui pour une même tâche, peut être parfois divisé par 20. Par exemple, le nombre de requêtes mysql qui pèse très lourd, s'avère parfois largement exagéré.

Comme la plate-forme devrait être mise rapidement sur pied, autant miser sur une solution existante, quitte à la customiser dans les moindres détails.
De plus, l'admin final ne doit pas forcément avoir besoin de compétences particulières d'où aussi l'idée de partir sur un moteur qui a été testé par une large communauté.

Bien sûr, il y a aussi magento pour ce type de gros site, mais les frais d'hébergement décollent à perf équivalente...

L'intérêt de l'open source est bien sûr la communauté. L'effort est distribué entre tous les membres de la communauté open source. Si vous avez besoin de qq chose, il est fort probable qu'un autre l'ait déjà fait. Si ce n'est pas le cas vous pouvez le développer vous même, et ensuite le partager. Plutôt que de réinventer la roue à chaque fois, on se focalise sur ce qui manque, ou ce qu'il y a à améliorer. Et tout le monde avance plus vite.

Bien souvent, un site atteint une vitesse de croisière en terme de visiteurs par jour, et s'en éloigne peu. Mais il est toujours rassurant de savoir qu'il peut gérer un nombre bien supérieur, plutôt que d'être constamment "limite". Ca permet d'assurer une qualité de service maximale, même aux jours de pointe...

[Damien Metzger]

200ms ça fait short, mais c'est possible. Je suis dans ces eaux-là sur PrestaStore : http://www.prestastore.com.
Note que le nombre de produits ou catégories ne changera pas grand chose, car ça ne fera pas grossir tes tables avec le temps (pas de problème de scalabilité donc). Le nombre de visites par contre oui.

PrestaShop permet d'aller vite, mais ça dépend clairement de ce que tu en fais.
Passe une ou deux heures à nettoyer les fonctionnalités inutiles dans les controlleurs et les classes métiers (produits personnalisables, prix degressifs...) et PrestaShop devient très light.
Et passe un peu de temps sur la conf de ton serveur SQL.

[Melki-Tsedeq]

Bonjour.

Comme le dis Damien Metzger 200ms ça fait short, mais c’est possible.

Il y a plusieurs techniques, mais si vous avez un fort trafic vous n’aurais pas le choix et devrais faire comme Damien, optimiser le code et utiliser uniquement ce dont vous avez besoin.

Cela va de soit qu’il faut aussi optimiser le css les images et minimiser le nombre de requêtes HTTP.
Limiter le nombre des modules au strict minimum.
Optimiser le cache et le rendre plus performant.
Optimiser les performances de PHP
Optimiser votre base de données SQL.

Vous pouvez aussi activer le gzip mais cela va faire monter en charge le CPU.

Le mieux c’est de mettre en place une politique de haute disponibilité et de faire une répartition de charge sur plusieurs serveurs Exemple :

1 Serveur Base de données
2 Serveurs Web / 1 pour les médias et 1 pour le traitement et l’affichage.

Cela apporte une augmentation significative de la sécurité et de la résilience par rapport à un seul serveur.
Coté performance cela améliore la vitesse de votre site en distribuant la charge entre plusieurs serveurs, maximisant la fiabilité, la réponse et le débit pour une meilleure expérience client. Et bien sur cela améliore votre référencement.

Cordialement.
Melki-Tsedeq

[ludo]

Entre 10,000 et 100,000 visiteurs par jour. Même si le site n'aura pas forcément une telle audience au début,

100.000 visiteurs unique quotidien mais vous rendez compte du traffic !!! ca fait au bas mot entre 1 et 2 millions de pages vus par jour. Heureusement que vous préciser que le site n'aura pas une telle audience au début... Rhaaa si vous aviez eu quelques millions d'euros de budget communication (emarketing, presse, radio, tv)

Le site comprendrait 15,000 catégories différentes,

15.000 catégories ... c'est cohérent ca ??? Avec 15.000 catégories comment vous faites pour l'arbo ??? Vous comptez les mettre sur 35 niveaux ? Je peux vous dire deja qu'on niveaux des performances (requêtes et affichages) ca va devenir super hard si vous envisagez plusieurs centaines de catégories.

pour un nombre de produits de 4,000 à 20,000.

Alors la c'est le sumum.... 15.000 catégories pour 4000 produits. C'est carrément n'importe quoi ! Même pour 20.000 ca fait 1.33 produits par catégories.

optimiser Prestashop pour un fonctionnement rapide ? (<200 ms/page)

Une vitesse absolue ne veut rien dire... pas plus que les quantité de requêtes... c'est pendant les pics de charges qu'ils faut un couple serveur/bande passante optimal... Et pour cela, on peut faire des calculs de répartition de charges et cela se prévoit et s'anticipe (il y a des ingénieurs qui vous feront ca très bien pour quelques milliers d'euros... une paille au vu du budget que vous devez avoir).

Pour ceux qui pensent que la rapidité n'est pas un point importante : (tout comme les admins de opencart, tellement sûrs d'eux quand ils affirment que les urls SEO ne servent à rien..... Rhaa bf). La rapidité d'un site internet est un point CENTRAL.

Vous devriez dire à la team d'Opencart de mettre ce tableau à jour... les croix rouge pour Prestashop sont plus d'actualité ! Pour l'url rewritting c'est effectivement une bêtise d'ignorer ce point... mais bon ils s'ignorent pas vraiment c'est juste pas une priorité pour eux (ce qu'on peut aussi comprendre). Message perso à Daniel Kerr "Daniel arrete de perde ton temps sur Opencart et viens nous rejoindre sur Prestashop et nous coder pleins de bons modules et gagner pleins de pognons sur Prestastore.

Les gens détestent attendre, et ce de plus en plus. Ils n'hésiteront pas à quitter votre site pour peu qu'ils attendent une seconde de trop.

Whaaa la révélation de la semaine ... Je me moque mais le pire c'est que c'est même pas vrai ! Je dit pas que l'acheteur adorent attendre 20 secondes l'affichage d'une page mais ca se joue pas à une seconde pour qu'il se barre en courant ... il y a tellement d'autre facteurs (dans le désordre) : le prix, l'offre, la confiance, la concurrence, ...

Pourquoi ? Parce que multipliée par le nombre de pages vues, cette seconde peut se transformer en minutes, et laisser place à un fort sentiment d'impatience. Résultat pour 75% des gens (étude à l'appui) : -> on zappe et directi google chez le concurrent

Encore une étude à la noix... style Fevad avec comme super échantillon représentatif "Les 10 plus gros site ecommerce français"... c'est sympa à lire ... si on fait parti des 10 ! Pour nous autres, il faut se baser sur nos propres expériences...

[jsmith]

Hey, pas la peine de s'exciter de la sorte ! Je pose une question, me répond qui veut... Ce serait sympa d'être aimable, et, plus important, de réfléchir avant de répondre. Je n'ai rien exigé rien de la part de la team, dont le boulot est déjà formidable. Je voulais juste savoir si quelqu'un avait déjà eu une expérience similaire, ou qui aurait une vague idée de sa faisabilité.

100.000 visiteurs unique quotidien mais vous rendez compte du traffic !!! ca fait au bas mot entre 1 et 2 millions de pages vus par jour. Heureusement que vous préciser que le site n’aura pas une telle audience au début… Rhaaa si vous aviez eu quelques millions d’euros de budget communication (emarketing, presse, radio, tv) smile

Erreur rectifié lors de mon second post, que vous n'avez pas lu, je parlais du nombre de visites par jour. donc plutôt entre 1000 et 10,000 visites. Ca n'a rien de transcendant pour un site internet.

15.000 catégories … c’est cohérent ca ??? Avec 15.000 catégories comment vous faites pour l’arbo ??? Vous comptez les mettre sur 35 niveaux ? Je peux vous dire deja qu’on niveaux des performances (requêtes et affichages) ca va devenir super hard si vous envisagez plusieurs centaines de catégories.

Pour reprendre l'exemple des imprimantes, chaque imprimante = une catégorie. Ensuite, si vous réfléchissiez un peu plus, vous sauriez qu'une même cartouche (produit) peut convenir à plusieurs imprimantes. Et d'ailleurs vous avez raison le ratio est exagéré, dans ce cas ci ce serait même plutôt 1 produit pour 5 catégorie. (Sans compter qu'on peut aussi créer toutes les catégories pour gagner du temps, et mettre les produits au fur et à mesure.)
La encore, vous auriez lu mon second post, l'exemple était donné.

Une vitesse absolue ne veut rien dire… pas plus que les quantité de requêtes… c’est pendant les pics de charges qu’ils faut un couple serveur/bande passante optimal… Et pour cela, on peut faire des calculs de répartition de charges et cela se prévoit et s’anticipe (il y a des ingénieurs qui vous feront ca très bien pour quelques milliers d’euros… une paille au vu du budget que vous devez avoir).

Ce n'est pas une vitesse absolue, mais un ordre de grandeur. Ca donne réellement une idée, pour autant qu'on connait un peu le système utilisé. Or je l'ai bien précisé. Ce temps correspond tout simplement à, par exemple, le temps moyen optimal de génération de la page d'accueil.
D'ailleurs, merci à Damien Metzger qui a tout à fait répondu à ma question, ( plutôt que de tenter d'affirmer son non-sens.)

Et bien sur que le nombre de requetes importe. Un chargement de page peut se faire en effectuant un nombre de requêtes différents (je parle bien sûr de req du même type). Et il faut être de mauvaise fois pour dire que ça n'influe pas sur le temps de chargement.
Virer un module, par exemple, c'est des requetes en moins, et peut vous faire gagner largement en temps de réponse.

Whaaa la révélation de la semaine … Je me moque mais le pire c’est que c’est même pas vrai ! Je dit pas que l’acheteur adorent attendre 20 secondes l’affichage d’une page mais ca se joue pas à une seconde pour qu’il se barre en courant … il y a tellement d’autre facteurs (dans le désordre) : le prix, l’offre, la confiance, la concurrence, …

Ce n'est pas parce que vous faites parti de cette minorité qui sait attendre, que tout le monde est comme vous. Peut-être aimez-vous les files et les embouteillages..
En tout cas, qui peut le plus, peut le moins : un site rapide convient à tous, un site lent convient à ceux que ça ne dérange pas..
(Moi ça ne me dérange pas spécialement c'est vrai. Mais je sais que l'internaute a tendance à être impatient à force d'être habitué à recevoir toutes les informations instantanément.)
Ensuite je vois pas pourquoi vous me parlez d'autres facteurs, j'ai parlé de condition nécessaire et non suffisante. Alors si vous voulez pousser votre logique jusqu'au bout, vous remarqueriez que votre dernière phrase est hors propos. Évidement qu'il faut jouer sur plusieurs plans, c'est juste hors sujet ici.

Encore une étude à la noix… style Fevad avec comme super échantillon représentatif “Les 10 plus gros site ecommerce français”… c’est sympa à lire … si on fait parti des 10 ! Pour nous autres, il faut se baser sur nos propres expériences…

( http://www.psu.edu/ur/2003/websiteappeal.html , cette étude confirme l'impatience des internautes dès 2003..)
La critique est facile... En plus, les temps de génération des différentes pages vues simultanément par des visiteurs différents s'ajoutent, et peuvent vite donner des temps de latence très longs.

[ludo]

Si si je m'existe j'adore ça !!!
Jt'ai juste clouer au mur pour le fun.

Juste qu'avec tes 3 posts au compteur
Ça fait parti du bizutage Prestashop !

Mais c'est bien... t'as tenu le choc !
Bienvenu sur Prestashop

[Thomy83]

Cela va de soit qu’il faut aussi optimiser le css les images et minimiser le nombre de requêtes HTTP.
Limiter le nombre des modules au strict minimum.
Optimiser le cache et le rendre plus performant.
Optimiser les performances de PHP
Optimiser votre base de données SQL.

Bonjour,

Avant de balancer des milliers d'euro pour un serveur dédié il serait peut être sympas d'appuyer sur les points ci dessus.
Je pense a moi en premier mais aussi au futurs lecteurs qui vont passer sur la page et qui n'ont pas de gros budget mais qui souhaitent tout de même améliorer la vitesse d'ouverture de page de leur site.

Pour ce qui est des modules, est ce qu'un module dé-activité c'est la même chose qu'un module qui sera désinstallé complet ? Je parle au niveau perf de la boutique.

Merci d'avance pour toutes vos réponses,
Jérémy.

Ps : A combien reviendrez un serveur dédié au minimum ?

[ludo]

Bonjour Thomy

Au niveau performance, je pense pas dire de bêtise en disant que "désactivé c’est la même chose qu’un module désinstallé".
A confirmer par la team.

Pour un hebergment dédié,compte 50€/mois.
Actuellement tu trouveras sur le marche (fr ou us) des offres de serveurs virtualisés beaucoup plus intéressantes (rapport perf/prix) que du pur dédié.

[Thomy83]

Hello,
Un modo peut il nous éclairer ?
Jeremy

[Waata]

Bonjour,

alors? d'après vous, un module désactivé est-ce la même chose qu’un module désinstallé svp?

Merci

Adrien

[jeckyl]

Quel est l'intérêt de conserver un module désactivé ?

A part si vous voulez conserver les réglages pour le réactiver après, car sinon, il vaut toujours mieux le désinstaller.

[Damien Metzger]

Désactivé ou désinstallé, c'est pareil niveau perf.

[Thomy83]

Merci Damien

[Waata]

Merci Mossieur!

[delete]

Pour ceux qui pensent que la rapidité n'est pas un point importante : (tout comme les admins de opencart, tellement sûrs d'eux quand ils affirment que les urls SEO ne servent à rien..... Rhaa bf). La rapidité d'un site internet est un point CENTRAL.

Vous devriez dire à la team d'Opencart de mettre ce tableau à jour... les croix rouge pour Prestashop sont plus d'actualité ! Pour l'url rewritting c'est effectivement une bêtise d'ignorer ce point... mais bon ils s'ignorent pas vraiment c'est juste pas une priorité pour eux (ce qu'on peut aussi comprendre). Message perso à Daniel Kerr "Daniel arrete de perde ton temps sur Opencart et viens nous rejoindre sur Prestashop et nous coder pleins de bons modules et gagner pleins de pognons sur Prestastore.

Daniel a pris connaissance de ce topic hier soir, nous en avons discuté et je me suis engagé à répondre, donc :

Droit de Réponse !

Bonjour,

Quand bien même le comparatif d'OpenCart / Prestashop ne serait pas à jour, la teneur de vos propos ne l'est pas non plus, je m'explique ;

SEO a bel et bien été une priorité pour l'équipe de développement OpenCart et le module est natif depuis la version 1.2.x sachant que nous en sommes aujourd'hui à la version 1.4.7 qui est de surcroit multi-boutique.

Daniel vous informe qu'il ne rejoindra jamais l'équipe Prestashop et qu'il croit pleinement en son projet et nous indique que son code est clair, fluide et apprécié par les membre de la communauté.

Pour ma part, je pense également qu'OpenCart à sa place dans le secteur du e-Commerce. Il ne réponds peut-être pas aux mêmes attentes que la solution Prestashop, je ne vais pas polémiquer sur la terminologie.

Concernant les performances, je laisse les adeptes du benchmarking en faire leur affaire !

J'en profite pour vous annoncer également la sortie de la version 1.4.7 Francophone en libre téléchargement sur le portail français.

En vous souhaitant une excellente continuation,

Cordialement,
Olivier a.k.a Delete,
OpenCart France

[surflibre]

Bonjour,

Vous avez pas blacklisté le ludo Mega VIP pour ces tas de c... déblatérées à la seconde?

[eBuildy Agency]

Moi j'ai beau chercher, optimiser, enlever tous les modules ... j'arrive jamais à des perfs merveilleuses .... l'unique solution est si tu es sur un dédié de mettre un proxy en front pour cacher en HTML la sortie de prestashop, la tu atteindras les 200ms à l'aise !

Après il faut surtout faire un thème from scratch, (adieu les 2000 lignes de CSS de prestashop ....) et ne pas hésiter à recoder un peu les classes Presta.

Si tu es sur un mutu, j'avais dév un module de cache HTML disponible sur notre boutique en ligne pour pas cher ;-) Enfin 30€ d'investissement et un peu recoder les modules pour les mettre en AJAX vaut mieux que 300€ d'hébergement ;-)

[jeckyl]

Moi j'ai beau chercher, optimiser, enlever tous les modules ... j'arrive jamais à des perfs merveilleuses .... l'unique solution est si tu es sur un dédié de mettre un proxy en front pour cacher en HTML la sortie de prestashop, la tu atteindras les 200ms à l'aise !

Après il faut surtout faire un thème from scratch, (adieu les 2000 lignes de CSS de prestashop ....) et ne pas hésiter à recoder un peu les classes Presta.

Si tu es sur un mutu, j'avais dév un module de cache HTML disponible sur notre boutique en ligne pour pas cher ;-) Enfin 30€ d'investissement et un peu recoder les modules pour les mettre en AJAX vaut mieux que 300€ d'hébergement ;-)

Euh, tu répond à qui est surtout tu parle de quelle version de prestashop car déterrer un topic vieux de 5 mois c'est étrange pour ce genre.

Mais peut être que tu avais besoin de placer une petite remarque sur ton module.

[ebuildy]

Ha oui j'avais pas vu la date ;-) en fait je cherchais "Prestashop performance" sur Google pour voir ce que les autres font pour améliorer leur site sur un mutualisé et c'était le premier lien, bien référencé ce forum ;-)

Je suis sur la version 1.4.3, tout juste installée avec les produits de démo, sur un hébergement mutualisé OVH, merci

[jeckyl]

Ha oui j'avais pas vu la date ;-) en fait je cherchais "Prestashop performance" sur Google pour voir ce que les autres font pour améliorer leur site sur un mutualisé et c'était le premier lien, bien référencé ce forum ;-)

Je suis sur la version 1.4.3, tout juste installée avec les produits de démo, sur un hébergement mutualisé OVH, merci

et tu as combien de comptes ?

[tobika]

Franchement Ludo , si c'est pour dire ce genre de truc...

c'est pas la peine!

[Galanid]

Beau déterrage qui m’intéresse pour le coup Le module de cache faire par ebuildy , fait du cache en ram ou sur fichier ?

[ebuildy]

Bonjour, notre cache sauve sur fichiers HTML la sortie de Prestashop, il peut ainsi fonctionner sur les hébergements mutualisés OVH, 1&1 etc ....

 

Ensuite lorsque le même URL est demandé, ce fichier HTML est envoyé ! Le panier et le blockuserinfo est en AJAX et donc se chargent une fois la page affichée !

 

On peut même directement router les requetes vers les fichiers HTML via htaccess pour ne pas charger le moteur Php ... et la ça trace !!!!!

[Galanid]

Merci pour ces infos

 

J'essaie de faire fonctionner le cache http varnish et prestashop de concert, mais un module pas une mince affaire.

Il faut mettre en place un petit module qui purge la page html mise en cache par varnish a chaque fois qu'une modification est faite automatiquement. et d'un autre coté ajouter les bonne directive sur varnish.

 

Comment tu gère la facon de purger tes pages en cache ? Exemple changement de prix ou encore de stock ?

 

cheers,

[nashtu3000]

Merci pour ces infos

 

J'essaie de faire fonctionner le cache http varnish et prestashop de concert, mais un module pas une mince affaire.

Il faut mettre en place un petit module qui purge la page html mise en cache par varnish a chaque fois qu'une modification est faite automatiquement. et d'un autre coté ajouter les bonne directive sur varnish.

 

Comment tu gère la facon de purger tes pages en cache ? Exemple changement de prix ou encore de stock ?

 

cheers,

 

Would you happen to be willing to share you varnish config with the world? I've searched for hours and haven't been able to find anything...