Aide générale Bloquer des robots indésirables
Reprise du message précédent
Merci de tes conseils .. Je vais attendre la sortie finale de ton v3 en php5.6 puis je verrai plus tard pour l'hébergeur, car j'ai renouvelé en Novembre, je vais perdre une centaine d'euro presque, un peu rageant ..
Salut.
J'ai pu faire un test SQL sur ma BDD (J'ai nettoyé toutes les BDD (tout supprimé, sauf mon site, y compris les répertoires FTP)) :
Citation:
Comment interpréter ceci?
J'ai aussi trouver ceci (Une bonne piste?) (Ce n'est pas ma BDD, mais le serveur: sqlx:33xx) :
Citation:
Voici des données que j'ai pu récolter (Connexions, ressources, processus.. (Mais je ne saurais les traduires)) :
Peut-être que ça vaut le coup de scinder le sujet? Edité par m-ickael Le 18/01/2016 à 10h15
J'ai pu faire un test SQL sur ma BDD (J'ai nettoyé toutes les BDD (tout supprimé, sauf mon site, y compris les répertoires FTP)) :
Citation:
Aborted_connects 71026
Connections 5994587
Max_used_connections 471
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_finished_connects 0
Threads_connected 8
Connections 5994587
Max_used_connections 471
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_finished_connects 0
Threads_connected 8
Comment interpréter ceci?
J'ai aussi trouver ceci (Une bonne piste?) (Ce n'est pas ma BDD, mais le serveur: sqlx:33xx) :
Citation:
Aborted clients7,1 kLe nombre de connexions avortées en raison d'une interruption du client sans fermeture adéquate de la connexion.
Aborted connects71,2 kLe nombre de tentatives de connexion au serveur MySQL infructueuses.
Handler read rnd next20,8 GLe nombre de requêtes de lecture de la prochaine ligne dans le fichier. Élevé si vous faites plusieurs parcours de tables. Ceci suggère que vos tables ne sont pas correctement indexées ou que vos requêtes ne sont pas écrites de façon à tirer parti des index que vous avez définis.
Handler read rnd305,6 MLe nombre de requêtes de lecture d'une ligne basée sur une position fixe. Ce nombre est élevé si vous faites de nombreuses requêtes qui nécessitent de trier les résultats. Vous avez probablement un grand nombre de requêtes qui demandent à MySQL de parcourir des tables en entier, ou vous avez des jointures qui n'utilisent pas correctement les clés.
Innodb buffer pool reads3 MLe nombre de lectures que InnoDB n'a pu faire à partir de la réserve, menant à une lecture directe d'une page.
Innodb row lock time avg 197 Le temps d'attente moyen pour acquérir un verrou, en millisecondes.
Innodb row lock time max 11,8 kLe temps d'attente maximum pour acquérir un verrou, en millisecondes.
Innodb row lock waits3,2 kLe nombre de fois qu'on a dû attendre pour un verrou.
Opened tables2,3 MLe nombre de tables qui ont été ouvertes. Si trop élevé, votre cache de table est probablement trop petite.
Qcache free blocks52,9 kLe nombre de blocs mémoire libres dans la cache de requêtes. Un nombre élevé peut indiquer des problèmes de fragmentation, qui peuvent être réglés par la commande FLUSH QUERY CACHE.
Qcache lowmem prunes12,9 MLe nombre de requêtes qui ont été retirées de la cache pour libérer de la mémoire afin de mettre en cache de nouvelles requêtes. Peut être utilisé afin de peaufiner la taille de la cache. La stratégie utilisée pour déterminer quelles requêtes seront retirées est LRU (least recently used).
Select range check 184,1 kLe nombre de jointures sans clés qui vérifient l'utilisation de clé à chaque ligne. (Si ceci est supérieur à 0, vérifiez soigneusement les indexes de vos tables.)
Slow queries245 Le nombre de requêtes dont le temps d'exécution a excédé long_query_time secondes.
Sort merge passes34,6 kLe nombre d'opérations de fusion effectuées par l'algorithme de tri. Si ce nombre est élevé, augmentez la valeur du paramètre sort_buffer_size.
Table locks waited181,5 kLe nombre de fois qu'un verrou de table n'a pu être acquis immédiatement, induisant un temps d'attente. Si ce nombre est élevé et que vous éprouvez des problèmes de performance, commencez par optimiser vos requêtes, puis subdivisez vos tables ou encore utiliser la réplication.
Aborted connects71,2 kLe nombre de tentatives de connexion au serveur MySQL infructueuses.
Handler read rnd next20,8 GLe nombre de requêtes de lecture de la prochaine ligne dans le fichier. Élevé si vous faites plusieurs parcours de tables. Ceci suggère que vos tables ne sont pas correctement indexées ou que vos requêtes ne sont pas écrites de façon à tirer parti des index que vous avez définis.
Handler read rnd305,6 MLe nombre de requêtes de lecture d'une ligne basée sur une position fixe. Ce nombre est élevé si vous faites de nombreuses requêtes qui nécessitent de trier les résultats. Vous avez probablement un grand nombre de requêtes qui demandent à MySQL de parcourir des tables en entier, ou vous avez des jointures qui n'utilisent pas correctement les clés.
Innodb buffer pool reads3 MLe nombre de lectures que InnoDB n'a pu faire à partir de la réserve, menant à une lecture directe d'une page.
Innodb row lock time avg 197 Le temps d'attente moyen pour acquérir un verrou, en millisecondes.
Innodb row lock time max 11,8 kLe temps d'attente maximum pour acquérir un verrou, en millisecondes.
Innodb row lock waits3,2 kLe nombre de fois qu'on a dû attendre pour un verrou.
Opened tables2,3 MLe nombre de tables qui ont été ouvertes. Si trop élevé, votre cache de table est probablement trop petite.
Qcache free blocks52,9 kLe nombre de blocs mémoire libres dans la cache de requêtes. Un nombre élevé peut indiquer des problèmes de fragmentation, qui peuvent être réglés par la commande FLUSH QUERY CACHE.
Qcache lowmem prunes12,9 MLe nombre de requêtes qui ont été retirées de la cache pour libérer de la mémoire afin de mettre en cache de nouvelles requêtes. Peut être utilisé afin de peaufiner la taille de la cache. La stratégie utilisée pour déterminer quelles requêtes seront retirées est LRU (least recently used).
Select range check 184,1 kLe nombre de jointures sans clés qui vérifient l'utilisation de clé à chaque ligne. (Si ceci est supérieur à 0, vérifiez soigneusement les indexes de vos tables.)
Slow queries245 Le nombre de requêtes dont le temps d'exécution a excédé long_query_time secondes.
Sort merge passes34,6 kLe nombre d'opérations de fusion effectuées par l'algorithme de tri. Si ce nombre est élevé, augmentez la valeur du paramètre sort_buffer_size.
Table locks waited181,5 kLe nombre de fois qu'un verrou de table n'a pu être acquis immédiatement, induisant un temps d'attente. Si ce nombre est élevé et que vous éprouvez des problèmes de performance, commencez par optimiser vos requêtes, puis subdivisez vos tables ou encore utiliser la réplication.
Voici des données que j'ai pu récolter (Connexions, ressources, processus.. (Mais je ne saurais les traduires)) :
Peut-être que ça vaut le coup de scinder le sujet? Edité par m-ickael Le 18/01/2016 à 10h15
D'accord.
Je viens de passer en MYSQL privé (8€ en gros / mois). On va voir ce que ça donne.
Je viens de passer en MYSQL privé (8€ en gros / mois). On va voir ce que ça donne.
Je fais un test pour le moment, je verrai le moment venu .. Pour le moment pas d'erreurs.
Bonjour,
Avis perso pour les hébergeurs:
En offre mutualisé , j'ai toujours serré les dents et toujours été à cran aussi, je suis comme Janus, je suis sur dédié du coté OVH. Je n'ai jamais eu de soucis.
Le soucis n'était pas de prendre les packs bases ( 1er prix).
- https://www.ovh.com/fr/hebergement-web/hebergement-pro.xml
Sinon voir : http://www.top10hebergeurs.com/
Swan
Avis perso pour les hébergeurs:
En offre mutualisé , j'ai toujours serré les dents et toujours été à cran aussi, je suis comme Janus, je suis sur dédié du coté OVH. Je n'ai jamais eu de soucis.
Le soucis n'était pas de prendre les packs bases ( 1er prix).
- https://www.ovh.com/fr/hebergement-web/hebergement-pro.xml
Sinon voir : http://www.top10hebergeurs.com/
Swan
Merci Swan 
Zéro erreur sur mon site depuis la BDD MYSQL privée ..
Pour ton lien sur OVH, c'est assez limite : Connexions simultanées : 30
Sur le deuxième lien j'ai vu EX2 avec des connexions illimités ..
Voir offre ici : https://www.ex2.com/hebergement-mutualise.html (ex2 entreprise) Edité par m-ickael Le 22/01/2016 à 10h53
Zéro erreur sur mon site depuis la BDD MYSQL privée ..
Pour ton lien sur OVH, c'est assez limite : Connexions simultanées : 30
Sur le deuxième lien j'ai vu EX2 avec des connexions illimités ..
Voir offre ici : https://www.ex2.com/hebergement-mutualise.html (ex2 entreprise) Edité par m-ickael Le 22/01/2016 à 10h53
Oui je sais, j'ai vu .. Mais d'un site à l'autre, certains hébergeurs ne figurent pas dans le top lol .. J'ai l'impression que c'est du grand n'importe quoi tout ça.
Bonjour,
c'est juste que certain site de "top" mettent les premiers car ils les ont contacté et en donné de l'argent.
D'autre n'essaye pas les hébergeur de type associatif (comme web4all) car pour eux association == amateur malgré que certains hébergeur associatif loue des baies dans des DC et surtout ont un parc "énorme" de serveur.
Cordialement, janus57
c'est juste que certain site de "top" mettent les premiers car ils les ont contacté et en donné de l'argent.
D'autre n'essaye pas les hébergeur de type associatif (comme web4all) car pour eux association == amateur malgré que certains hébergeur associatif loue des baies dans des DC et surtout ont un parc "énorme" de serveur.
Cordialement, janus57
D'accord, mais pour différencier les bons des mauvais, c'est une autre histoire. Dans tous les cas j'ai payé jusqu'en Novembre 2016, donc je vais pas perdre 100€ pour reprendre un abonnement à 100€ ^^
m-ickael:
Bonjour,
c'est pas vraiment 100€ si on prend web4all (3.6€ TTC * 12 => 43.2€ TTC/12mois)
Sinon pour les 100€ perdu chez nuxit perso j'ai pas de solution mis à part le fait de choisir de hébergeur qui propose le paiement sur 1/3/6/12 mois ce qui permet d'éviter ce genre de situation.
Après si tu vise des hébergeur qui propose de "l'illimité" forcément là c'est toujours plus cher (et pas illimité dans 99% des cas).
Cordialement, janus57
D'accord, mais pour différencier les bons des mauvais, c'est une autre histoire. Dans tous les cas j'ai payé jusqu'en Novembre 2016, donc je vais pas perdre 100€ pour reprendre un abonnement à 100€ ^^
Bonjour,
c'est pas vraiment 100€ si on prend web4all (3.6€ TTC * 12 => 43.2€ TTC/12mois)
Sinon pour les 100€ perdu chez nuxit perso j'ai pas de solution mis à part le fait de choisir de hébergeur qui propose le paiement sur 1/3/6/12 mois ce qui permet d'éviter ce genre de situation.
Après si tu vise des hébergeur qui propose de "l'illimité" forcément là c'est toujours plus cher (et pas illimité dans 99% des cas).
Cordialement, janus57
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie