Os Commerce

[mbla]

Bonjour

Je voudrai savoir si des clients 720plan y ont mis en place une boutique en ligne avec OS COMMERCE, pour partager nos expériences
Merci

[Casa]

J'avais la même question à poser, le 720plan est-il à même de soutenir les requêtes parfois un peu lourde d'osCommerce avec un catalogue conséquent

[mbla]

C'est justement, parcequ'avec la montée en charge de notre boutique, nous nous posons des questions sur son bon fonctionnement, et nous souhaitons comparer les expériences de ceux qui, comme nous, ont choisi ce plan pour l'héberger.
Nous avons eu notre base désactivée pour utilisation excessive de CPU et aimerions en connaitre les causes exactes.
Merci de nous dire si vous aussi vous avez rencontré ce type de problèmes.

[Casa]

Donc vous êtes déjà sur 720plan et c'est bien ce que je craignais, les requêtes d'osCommerce semblent, d'après ce que vous dites, trop lourdes pour du mutu. Personnellement j'ai testé osCommerce sur un 60GP simplement sans réelle boutique mais avec un catalogue de quelques 300 items, et effectivement si je n'ai pas eu de okiller, j'ai néammoins eu souvent affaire à des too many connection ou des lenteurs sql ou perte de connection avec le sql avec des temps de parsing allant de 0.150s au mieux à 7s ! au pire. j'avais attribué ça aux problèmes réseaux qu'a rencontré OVH ces derniers temps, peut-être le script est-il lui aussi trop lourd.
Il est donc effectivement intéressant de savoir si d'autres essais ont été faits sur mutu en ce sens.

[PONKO]

Bonjour,
Ma boutique fonctionne parfaitement depuis 6 mois, sur le plan 60gp :)
Par contre je n'ai pas installé la dernière version j'ai la creload5MS1
Plus de 200 produits, et des clients réguliers.
Faites attention à ne pas utiliser l'outil backup du script !! ça utilise trop le processeur d'ovh.
Sinon pas de probleme de mon côté. Attention à vos modules des banques de paiement en ligne.
Bonne journée,
Xavier
http://boutique.leprodelacuisine.com

[Casa]

Merci pour toutes ces infos et précisions.
A tout hasard avez-vous activé les logs de temps de parsing et avez-vous eu ces derniers temps des ruptures de connexion sql ou too many connections ?

[mbla]

Infos volume pour notre boutique :
- entre 600 et 900 visites/jour et 6000 pages vues
- une dizaine de commandes/jour
- 5000 articles dans une centaine catégories et sous-catégories
- taille de la base Mysql => 6.31 mégas
Curieusement , alors que depuis début février les coupures sous des prétextes divers étaient légion, depuis, le crash electrique d'il y a quelques jours et la panne qui a suivi, tout semble revenu dans l'ordre ! La hotline me conseille de changer de version de PHP, mais franchement, je pense que cela vient plutot du coté OVH... et chez vous ? ça se passe comment ?
Merci

[Casa]

Personnellement j'avais mis en test avant le crash une version personnalisée, catalogue très réduit, pas de visiteur (sauf moi en test) et je n'arrêtais pas d'avoir des too many connections ou pas de connection du tout. j'ai donc abandonné le 60gp.

[PONKO]

Bizarre ce que vous dites là. Quelle version utilisez vous ? Pour ma part, j'utilise la creload 2.2 ms1, et lors de l'installation j'ai mis les sessions dans la base mysql.

J'ai plus de 1 000 visiteurs par jour.

et vous aviez mis quoi comme version ?

Bonne journée,
Xavier

[Casa]

la 2.2ms2 traduction perso, sessions en mysql ou pas, sur le serveur sql4
les temps de parsing du listing était totalement aléatoire, de 0.15 à 7s ! Ce que j'ai modifié, à la fois dans la base et dans les modules (listing avec les options de produits et achat immédiat) ne justifie pas ces erreurs, sans parler du fait que j'ai totalement réoptimiser la base en adaptant les taille de champs au mieux, mettant des index sur des champs de tri (ces index ne changeant qu'en cas d'insertion de nouveaux produits donc pas lors de la consultation client)
un défaut des script d'osc c'est : ouverture de la connection sql en début de page et fermeture tout à la fin, melange des scripts php et connexion sql avec le code hmtl. Bref si le serveur web rame ou la connexion http vers le client rame, la connexion sql persiste plus longtemps, amenant des erreurs sql. j'ai rectifié ça au mieux en balançant tout le code php en début de fichier, effectuant l'ensemble des requetes et mise des résultats en variable, fermant la connexion, affichant la page html via le cache orb et réouvrant la connexion si nécesaire à la fin pour maj des compteurs et sessions. ça n'a rien changer question erreurs mais c'est de toute façon mieux.
mais je ne suis pas le seul ces derniers temps a avoir eu des too many connections non justifiée et des server introuvable, j'en déduis que le 60gp+sql4 était largement coupable. comme je ne veux pas risquer en production d'avoir les memes ennuis sur un 720plan, j'hésite vraiment et lorgne du coté dédié.

[mbla]

Interessant l'avis de Casa, car cela nous prouve que la solution préconisée par OVH d'optimiser les requêtes, si elle ne peut pas faire de mal, en tous cas, ne solutionne rien..... Il va falloir chercher ailleurs......
En tous cas, merci de ces témoignages qui devraient nous permettre d'aller vers une solution.....
Si d'autres participants ont des idées.... elles seront les bienvenues

[Casa]

Oui parce que pour ce qui est optimisé, je suis vraiment allé au plus serré question type de champs, indexage (qui ralentit les update, mais j'en ai pas, j'ai que des select) et la gestion des connexions sql tout regroupé en début de fichier, fermeture, réouverture (éventuelle à la fin pour maj des compteurs) et refermeture connexion.
Je ne dis pas que ça marche pas, je constate simplement que ça n'a pas amélioré mes problèmes de too many connections (alors qu'il n'y a que 1 visiteur car le site n'est pas ouvert) ou problème de server not found ou autre problème sql. Je pense vraiment qu'ils ont un problème sur le sql4 ou de liaison sql4->60gp et que cela mériterait plus d'attention depuis le temps qu'on le signale.