Aller au contenu

Sujets conseillés

Posté

Bonjour,

Le serveur de notre site de e-commerce plante (erreur MySQL "too many connection") de façon intermittente lors des crawl google. Une analyse nous conduit à penser que cela provient des appels images produits. Le catalogue comporte 2.000 références, soit environ 10.000 photos réunies dans un dossier unique. Le site est en php, mysql, serveur dédié ovh, url rewriting... Avez-vous déjà rencontré une situation similaire. Nous avons trouvé quelques post traitant de ce problème, mais pas de solutions.

Nous envisageons deux méthodes pour contourner le problème et aimerions avoir l'avis des pros du référencement avant d'opter pour l'une ou pour l'autre :

a- php génère actuellement des pages html, et nous nous demandons si le fait de passer les lignes faisant appel aux photos en xhtml ne serait pas une solution, car nous avons lu que les images ne sont pas indexées en xhtml.

Nous ne pouvons pas basculer l'ensemble du site en xhtml, le site comporterait donc des pages html contenant des liens en xhtml ;

b- seconde piste, interdire à google l'indexation du fichier image en jouant sur le tag robot.

Les images étant dans le haut du code des pages crawlées, nous nous demandons si le spider va bien indexer le contenu qui se trouve après ou s'il renoncera.

Dan, notre site étant sur le segment olé-olé du e-commerce, je n'ai pas publié son URL dans ce post. Si tu m'y autorises, je le ferais pour une meilleure information des membres, sinon je le communiquerais par MP aux personnes qui souhaiteront l'avoir :)

D'avance je vous remercie de vos conseils et idées.

Sylvain

Posté

il te reste, je pense, une possibilité : si le visiteurs est un robot, alors ne pas afficher les images. Du coup, quand google passera il n'aura pas d'image

Posté

L'étude des log nous a permis de cerner le problème avec google. Pou rles autres spiders nous ne savons pas. Néanmoins comme google passe chaque jour sur le site ce serait toujours un problème d'éliminé.

Posté

Avec une règle dans le htaccess, précédée d'une directive RewriteCond se basant sur le USER_AGENT. Celui-ci est toujours transmis par les principaux moteurs... donc suffisament fiable pour cet usage.

Katmars, OK pour l'URL, mais rends la non cliquable (-http:// ) :)

Posté

Bonjour Dan,

Merci pour le conseil.

Pour l'URL c'est www . dvdtek . fr (et là, c'est du non clicable !)

Sylvain

Posté

Je ne crois pas que les images aient quelque chose à voir... elles ne sont pas dans la base tout de même ?

Combien as-tu de connexions mysql maxi en simultané ? Parce qu'avec les 100 connexions de base, je ne pense pas que cela puisse être la raison, sauf si tu utilises des connexions persistantes.

As-tu regardé si tu as des requêtes "slow_query" ? (Dans tes logs mysql)

Tu peux aussi augmenter le nombre de connexions simultanées, le passer à 200 et redémarrer mysql. Mais sur le serveur du Hub, il est très rare qu'on dépasse une dizaine de connexions simultanées, même en étant plus de 300 à bord :)

Posté

Ben en fait je ne sais pas exactement en général le serveur plante autour des 2000 d'après les messages d'erreurs retournés avant le plantage.

Pour les connexion persitente je pense qu'elle le sont toutes.

Par ailleurs le repertoire qui contient les image est vraiment enorme ( 344064Ko ). Ca serait pas un peux dur pour le proc de fouiller la dedant par hazard ?

Posté

Pardon j'ai du faire une confusion, le nombre de connexion simultanées est bien de 100.

Par rapport au référencement, y a t'il un inconvenient à interdire un repertoire pour les moteurs? A mon niveau je trouve que c'est quand même la solution la plus facile?

Posté
Je ne crois pas que les images aient quelque chose à voir... elles ne sont pas dans la base tout de même ?

<{POST_SNAPBACK}>

je ne pense pas mais l'url de ces dernières doit y etre je pense

Posté
je ne pense pas mais l'url de ces dernières doit y etre je pense

<{POST_SNAPBACK}>

Je viens de vérifier et les URL des images sont bien dans une table "article_photo" de la base sous la forme suivante :

id id_article nom filename ext path

1 18 rs AAA00018_rs jpg img/photos/

2 18 ra AAA00018_ra jpg img/photos/

Etc...

Cela a-t-il un impact ?

Sylvain

Posté

Bonjour,

je rejoins entièrement la solution proposée par ex-floodeur. Et je pense aussi que si SQL est sollicité pour les URL des images, çà doit bien aider à le planter vu le nombre d'images/page.

Cela étant, juste 2-3 questions :unsure: :

nous avons lu que les images ne sont pas indexées en xhtml.

Ah bon ? :o Quelqu'un a de la doc sur la question ? :huh:

Nous ne pouvons pas basculer l'ensemble du site en xhtml, le site comporterait donc des pages html contenant des liens en xhtml ;

Soit je n'ai pas tout compris, soit je pense que çà ne poserait aucun problème :unsure:

Par ailleurs, indépendamment de la surcharge SQL, il y a clairement une grosse surcharge au niveau du serveur tout court. L'affichage des pages est très long chez moi (ce n'est pas ma connexion, elle est en béton armé et je viens de tester avec d'autres sites pour m'assurer que ce n'est pas un ralentissement sur mon DSLAM), et le code source (html) est effectivement super redondant. Quand Google aura fini de planter la BDD, sérieusement jetez un oeil là-dessus ;)

Bonne chance

Posté

j'ai eu moi aussi un de site planté au moment ou ggole et passé et mes pages se sont retrouvées dans google sans titre ni description, ca fait maintenant 4 semaines, le GoogleBot risque t il de repasser sur mon site et de reindexé mes pages ou je suis bon pour me prendre un hebergeur serieux et nouveau nom de domaine???

Posté

Merci de vos précieux conseils les amis :)

Nous avons décidé de plusieurs choses : nous prennons un serveur plus puissant, nous avons interdit le fichier photos aux robots, nous allons vérifier que les sessions mysql sont bien fermées sur chaque page, nous retravaillons sur le fichier image en le scindant pour le rendre plus facilement accessible.

Encore merci pour vos contributions.

Sylvain

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...