Florian Lemaitre Posted July 12, 2018 Share Posted July 12, 2018 Bonjour, Je me suis toujours demandé pourquoi Prestashop ne gérait pas les transactions SQL pour la création de ses commandes. Malheureusement hier j'en ai fait les frais pour la première fois. Le serveur SQL qui sature et les tables qui se retrouvent en Deadlocks résultant en des commandes à moitié créées sur le site. Sur un site à 300/600 commandes l'heure je vous laisse imaginer les dégâts si je n'avais pas réagit dans les 5 minutes pour passer le site en maintenance. Je me demande pour quelle raison Prestashop ne met pas en place un système plus robuste de transaction pour s'assurer qu'une commande ne soit jamais corrompue en base de données ? Il me semble que l'intégrité des données est un point primordiale pour un système de vente en ligne ? Au plaisir de vous lire Link to comment Share on other sites More sharing options...
cyssoo Posted July 12, 2018 Share Posted July 12, 2018 Hello Florian, J'ai fait il y a peu l'expérience du SQL sous Prestashop versus l'utilisation propre de la POO. Le bilan a été sans appel : un site détruit par un prestataire qui tapait en plein dans la database, contre une victoire de la bonne vieille méthode de l'orienté objet. Pour l'exemple, l'outil qui tapait en plein via SQL en database réécrivait les identifiants de tous les fournisseurs, pour ses propres besoins. Le résultat a été de rendre intégralement inopérant le site (que j'ai du déboguer, je vous laisse imaginer ma colère quand j'ai constaté cela). La POO, c'est la vie ! Direct en base de données, c'est la porte ouverte à nawak... A 300/600 commandes à l'heure, Prestashop gère sans souci, je me poserai plus la question de la conf machine, et du type de database utilisé. Là il s'agirait plus de gestion de charge que de Prestashop, qui au final fait son taf. C'est quoi la conf serveur et la version de Presta au passage ? Link to comment Share on other sites More sharing options...
Florian Lemaitre Posted July 24, 2018 Author Share Posted July 24, 2018 Bonjour Cyssoo, Côté Apache, le serveur se la coule douce à 10% de CPU et de RAM. Côté MySQL le serveur est un peu plus en panique et je viens d'en trouver la cause... la fonction "updatePhysicalProductQuantity" qui prend de plus en plus de temps à s'exécuter au fur et à mesure des commandes. Vu que je ne gère pas les stocks sur mon site, un petit "return true;" avant l'appel de cette fonction a permis de gagner énormément de temps dans le traitement des créations de commandes. A savoir que le site a un taux de conversion proche de 100%, la validation de commande est le point qui génère le plus de charge. Aussi je te rejoins sur la POO, malheureusement Prestashop a encore un long chemin à faire de ce côté là... Vivement le full Doctrine ;). Cordialement, Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now