PieceMobile Posté 2 Mai 2018 Posté 2 Mai 2018 (modifié) Bonjour à tous Je fait face à un petit problème technique dont l'issue semble pourtant complexe à mettre en oeuvre pour les 4 prestataires à qui j'en ai parlé. J'ai un produit avec 14 000 000 de combinaisons. Je précise que ça n'est pas évitable. La légende urbaine veut que Prestashop ne gère pas autant de combinaisons ( il gère très bien 250 000 adresses x 140 000 clients x 30 groupes x ect.. ). En fait le seule et unique problème intervient en back office lorsque on veut accéder à la fiche produit pour l'affichage de l'onglet Combinaison : erreur 500. J'ai essayé un module mais pas encore concluant ( créer des pb et à ce jour ne fonctionne pas ). Je voudrai tout simplement que cet onglet ne se charge pas, et du coup, lorsqu'on sauvegarde un produit cela n'efface pas tout les combinaisons et autres problèmes que je n'anticipe pas puisque je ne code pas. Cela vous parait "faisable" dans un temps relativement court ( quelques heures) et sans hypothéquer totalement la suite de l'avenir du site ( sans trop toucher au "coeur" ) ? Sinon est ce possible d'afficher la page pour éviter l'erreur 500, même quitte à attendre 2 heures le chargement des combinaisons avant de sauvegarder le produit ? Avez vous des remarques techniques ou des idées pour contourner ce problème ? ( je précise aussi que j'ai quand même besoin de l'accès BO fiche produit pour d'autres questions ). J'ai du mal à croire à être le seul a avoir ce problème, et que tout les autres on pu contourner le problème avec ce module uniquement et tous sans exception ( de plus un module usine a gaz avec des fichiers a modifier manuellement ect... ). En vous remerciant d'avance pour vos idées / pistes.. Modifié 2 Mai 2018 par PieceMobile ortho
Dan Posté 2 Mai 2018 Posté 2 Mai 2018 Le masquage de cet onglet devrait pouvoir se régler par réécriture d'URLs... Le tout est d'analyser correctement l'URL qui est appelée lorsqu'on clique sur l'onglet Combinaison... As-tu un exemple d'URL ? Je devrais pouvoir la retrouver dans les logs, si tu me donnes au moins le nom de domaine. Mais il est aussi possible que php manque de mémoire RAM... l'analyse du log d'erreur devrait donner quelques infos supplémentaires.
PieceMobile Posté 2 Mai 2018 Auteur Posté 2 Mai 2018 (modifié) oui , celle ci, j enlève les paramètres /retiré/ Modifié 2 Mai 2018 par PieceMobile url retirée
PieceMobile Posté 2 Mai 2018 Auteur Posté 2 Mai 2018 Il y a 3 heures, max-vai a dit : Bonjour, Hormis la question du back-office, j'y reviens plus tard, il y a la question du front office qui aura exactement les mêmes problèmes. Le back-office ne peut pas afficher ces 14 millions de déclinaisons, ok, mais le client en front, comment va-t-il faire ? Il faudra aussi traiter cela, et même si techniquement il y a des solutions, elles seront plus compliquées que dans le back car il faudra travailler l'ergonomie. Il y a plusieurs pistes : 1) Ne pas avoir 14 millions de combinaisons.(si si j'ai lu le post ) Il faut en fait 14 millions de produits à la place et travailler seulement sur le template Prestashop. C'est à mon avis la plus simple et la meilleure des solutions en terme de maintenance car seul le template est affecté. Pas de surcharge, pas de modification du cœur. 2) Si tu retiens les 14 millions de déclinaisons, et bien franchement, je ne vois pas comment répondre de manière exhaustive sur un post ici ! L'erreur 500 vient très certainement d'un manque de mémoire du serveur. Il faut augmenter la RAM allouée à php. Est ce possible ? Et si oui, est ce que le back-office est encore fluide (je parie par avance que non). Une solution, c'est de charger à la demande, la déclinaison nécessaire - facile à dire, très gros taf, impossible sans massivement surcharger Prestashop (les mises à jour seront à oublier). Ensuite il faut une solution pour le front. Et ne pas oublier les modules additionnels, peuvent ils gérer ce volume ? Et des applications tierces qui utilisent le webservice de Prestashop ? Là clairement, impossible. Bref, cette solution est effectivement très complexe, probablement la plus couteuse. 3) Passer à Magento Le principe des produits simples & groupés de Magento permettront de faire ça bien plus facilement. Grosso modo, c'est le cas 1 exposé sur Prestashop. Bon courage ! 1) Il me semblai que le Front ne chargeai pas les combinaisons, mais allait chercher lorsque les caractéristiques sont modifiées. En tout cas pour avoir testé à 20 000 combi, pas de problèmes particuliers. J'espère que tu te trompe car sinon le problème est en effet tout autre et la question ne se pose même plus! Pour l'anecdote 14 millions c'est en ayant déjà fait un très gros travail de réduction en amont 2) On ne parle que du BO produits, en fait un BO produit, on y va une fois tout les 6 mois, et pour 80% du temps, en plus, un store commander ou manager fait le taff. Le reste du BO n'est pas ( visiblement) alourdi à part au moment de la génération. Pour la RAM alors si j'ai une erreur 500 a 20 000 produits, je ne pense pas qu'une augmentation suffirai aller dans des millions, du coup snif. J'oublie la charge a la demande vu ce que tu me dit ca parait trop lourd en ressources pour un démarrage. 3) Merci pour l'info, du coup peut être la plus simple des solutions...
Dan Posté 2 Mai 2018 Posté 2 Mai 2018 Dans les logs j'ai des erreurs comme celle-ci : Allowed memory size of *** bytes exhausted Je t'ai doublé l'espace mémoire pour php... il était déjà bien haut. N'as-tu pas essayé ce site sous php 7 ? Tu as la possibilité de le choisir au niveau d'un domaine.
PieceMobile Posté 2 Mai 2018 Auteur Posté 2 Mai 2018 PHP 7 et/ou up de la limite m'ont permis d'ouvrir celui à 2 000 combinaisons déjà. La suite demain sur un 20 000...
PieceMobile Posté 2 Mai 2018 Auteur Posté 2 Mai 2018 La suite sur 10 000 combinaisons : OutOfMemoryException in OptionsResolver.php line 978:Error: Allowed memory size of ******* bytes exhausted (tried to allocate 20480 bytes)
PieceMobile Posté 2 Mai 2018 Auteur Posté 2 Mai 2018 (modifié) Du coup quelques infos quand même : En fait dans le BO produit, même si Presta "charge" ( je sais pas si c'est le mot ) les combinaisons dans la mémoire, tant qu'on ne va pas sur l'onglet combinaison, en tout cas, on a possibilité d'aller dans les autres, et sans se taper le chargement "physique" du navigateur ( 20min pour 1600 combinaisons ). Donc de ce côté là, tout va bien, store commander gère très bien les combinaisons et PHpmyadmin aussi d'ailleurs. Dan peut on encore augmenter si c'est possible la mémoire ? Modifié 2 Mai 2018 par PieceMobile
Dan Posté 3 Mai 2018 Posté 3 Mai 2018 Il y a 9 heures, PieceMobile a dit : Dan peut on encore augmenter si c'est possible la mémoire ? Je l'ai à nouveau doublée !
PieceMobile Posté 3 Mai 2018 Auteur Posté 3 Mai 2018 Il semble que 10 000 soit de toute manière un maximum absolu, je me débrouillerai avec. Ca fonctionne mais il ne faut pas ouvrir le sous onglet Combinaison. 20min pour ouvrir le BO produit en question et je pense autant pour la sauvegarde. En front office ça ne semble poser aucun problèmes particuliers.
xmediacreation Posté 7 Juin 2018 Posté 7 Juin 2018 Juste une petite question, c'est quoi le produit, et le type de combinaison ? En fait mon idée c'est, est ce qu'il n'y aurait pas moyen de les gérer hors prestashop, tout simplement ?
xmediacreation Posté 7 Juin 2018 Posté 7 Juin 2018 14 000 000, j'imagine donc que c'est un produit "configurable", donc pas de gestion de stock à assurer... En créant un produit "personnalisable" et en modifiant l'affichage des choix pour afficher tes successions de listes de choix (en ajax par exemple), les options ne seraient utilisées qu'à l'affichage (stockées en cache en plus), et tu recevrais juste la commande avec écrit option 1 | options 2 | option 54 | option 18 | options 98...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant