Bande passante et requête SQL comment faire ?

[onlylove]

Salut j'ai un 60GP sur ovh, donc 30giga/mois et bande passante suivant le réseau (super)
600 mo d'espace ok.
Seulement j'utilise énormément ma base sql, avec des requêtes élaborées, plus du chargement d'images sur des sites qui affichent des images de mon site.
ma question: c'est comment faire pour être fluide, l'affichage d'une page demande énormément de ressources, seulement je ne sais pas si c'est l'offre, le sql qui rame, ou autre...

Je pense m'orienter vers un autre hébergeur qui propose le traffic illimité pour moins cher mais est-ce-que ça va plus fluide?

 

[finstreet]

elles sont bien toutes optimisées et toutes absolument indispensables tes requetes ?

M'en suis trouvé une pas super utile... mais qui prenait 0,3 à se faire... je l'ai lourdé

 

[onlylove]

Merci pour ta réponse rapide, ouai et bien j'ai tout tout optimisé niveau requete, j'ai même regarder les sites de tuning sql 8) retiré les SELECT DISTINCT qui bouffe un max, et j'en arrive toujours au même point.
Quand j'affiche 50 résultats c'est bon mais dès que je tape dans le 100 résultats en limite sql, ou plus la page met 25 secondes à s'afficher.

J'utilise en plus des requetes sql quelques fonctions de trie,... php, mais voilà...
Peut-être des fonctions ereg() explode() strpos() sur 100 requêtes rendent le serveur super lent, je ne vois pas ...

De là à transferer tout ailleurs c'est délicat car mon service ne sera plus valide 24h
Donc face au peu d'info sur la bande passante d'ovh pour du 60GP je ne sais pas si rester dans cette gamme est bien ou passer au dessus (dédié ou traffic illimité ailleurs à un sens!!!) sachant que j'ai besoin au max de 300 Mo d'espace et pas 190 giga des serveurs dedies (hors de prix)

En fait ma grande question c'est si on a pas besoin de bcp d'espace est-ce-que le 60 GP est bien même pour les sites à fort traffic, surtout forte demande ?

 

[david96]

Moins tu sollicites la base SQL, mieux sait, c'est pourquoi si tu peux opter le plus souvent pour une mise en cache il faut le faire.
Je t'envoie sur une excellente thread de fandecine à ce sujet :
https://www.webrankinfo.com/forum/t/script-mise-en-cache-des-pages-php.28614/

 

[finstreet]

question bête... je ne connais pas l'actualisation des résultats de tes requetes... mais tu as aussi la possibilité de générer la requête disons toutes les minutes, heures, jour... de la coller dans une table et de la récupérer sans pb après

J'ai des infos que j'ai volontairement à 24 h pour les mises à jour... le cron dure ... longtemps lol mais il tourne à 3h du mat' ... y'a pas de surchage après


ps : la mise en cache est très bien aussi

 

[onlylove]

Super topic sur la mise en cache, je vais regarder le procédé qui me parait assez délicat...
Sinon je suis obligé de générer des requetes tres souvent donc faut que je calcule le meilleur cache et c'est dur.
Je vais déjà mettre des marqueurs de durée (en secondes) dans les requetes et apres je pourrais essayer d'agir et trouver une fonction php moins gourmande.
Ah là là c'est pas facile de gérer un gros site.

 

[julienr]

j'ai lu, tu dis que tu utilises quelques tries, attention si tu n'as pas d'index sur les colonnes de trie c'est certain que ta requete va partir en live si tu as quelques dizaine de millier de lignes.
Un truc bien pratique c'est de se constituer un visual debug que tu actives avec un paramètre GET sur l'url. Dans ce mode tu loggues toutes tes requetes dans une global que tu affiches à la fin de ta page. En plus tu rajoutes une mesure de temps d'exécution. Super pratique quand tes requêtes dépendent d'un contexte particulier...

 

[onlylove]

Effectivement je me demande vu que sur mes tables je n'ai pas mis de clef ID, si ce n'est pas un tort ? je n'ai mis que des champs varchar
Tu entends quoi par index de colonnes ?

Pour la mesure du temps j'essaie de le faire mais pour le debug je sais pas comment vraiment.
Quand j'affiche les enregistrements de la base ça coule a peu pres mais des que je traite dans le while les données dans des fonctions php c'est l'enfer du chronomètre temps

 

[finstreet]

euh t'as aucun index sur tes tables ? ni de clé primaire ? ah ben c sur que ca doit ramer meme avec 10.000 lignes

 

[onlylove]

Bah non en fait j'ai été négligeant pour aller plus vite ;( : j'avais une table simple à faire.

En fait j'utilise toujours un id auto increment(clé primaire) et là j'en avais pas besoin mais je vais m'atteler de le remettre !!! car je pense que ça vient de là peut-être...


et j'espere revenir avec le sourire pour dire : ça tourne

 

[finstreet]

si tu utilises phpmyadmin... tu regardes dans ta requete, et dans ta table, la colonne qui te sert le plus lors des WHERE... notamment les jointures... et là tu indexes cette colonne... ca double le poids de ta table, mais tu peux passer de 7-8 secondes à 0,03 secondes (cas réel que j'ai testé lol)

 

[onlylove]

Cool cool ça a vachement améliorer le processus les clefs. :wink:
Mais ça pourrait être 10 fois mieux je pense.
J'ai bien php admin, mais j'ai plus de 80 000 enregistrements en permanence et ça grossit donc je dois absolument optimiser.
Alors pour donner un exemple en phrase :

Marie a ecrit dans les rubriques suivantes : rubrique1,rubrique2,rubrique3 ....

$requete0=mysql_query("Select distinct rubriques FROM record where membrenom="marie" order by timeecrit desc");
$valeur0=mysql_num_rows($requete0);

en considerant que quant on ecrit un message on ecrit dans la table record le nom de l'ecrivain=marie et la rubrique ou elle a posté son message.
Ensuite on peux savoir dans quelle rubrique le membre marie a ecrit et l'afficher et savoir dans combien de rubriques différentes elle a ecrit.

Coupler à d'autres requetes bien sur c'est un exemple rapide.

Comment indexer la colonne ici avec le where, car si marie ecrit beaucoup et qu'il faut afficher des infos en plus c'est long...Et si plusieurs membres font la meme requete c'est dur....

J'ai aucune idée de l'indexation des colonnes et je crains de tout faire planter lol
http://www.manuelphp.com/mysql/indexes.php pas reussit à saisir.

 

[finstreet]

ben là déjà en indexant la colonne membrenom ca sera plus rapide

sinon je crois qu'il est plus rapide de travailler sur des chiffres que sur des varchar... en gros si tu avais un identifiant qui identifiait marie par un numéro... ce serait plus simple

 

[onlylove]

Ok merci donc dans php admin la colonne membrenom je clique sur INDEX à droite?
Et au niveau de la requête ya rien à changer c'est automatique?
C'est incroyable le nombre de trucs à savoir quand tu programmes ... 8O

 

[xTrade]

Ok merci donc dans php admin la colonne membrenom je clique sur INDEX à droite?
Et au niveau de la requête ya rien à changer c'est automatique?

Ouaip

C'est incroyable le nombre de trucs à savoir quand tu programmes ... 8O

Ben ouai

Ah, j'oubliais : j'espère que tu n'as pas un 90 plan, t'as pas intérêt à faire ramer mon site :lol:

 

[finstreet]

oui

en meme temps imagine le nombre de règles de grammaire que tu mets en place à chaque fois que tu écris... mais à force tu le fais naturellement... ben là... c pas pareil lol

 

[onlylove]

Oui oui j'ai cliqué sur index sur la colonne, et je ne vois pas de suite le résultat


EDIT : là j'ai indexé le champ et c'est ultra RAPIDE : merci les gars


Si c'est bien d'indexer pourquoi ne pas indexer tous les champs ?

 

[onlylove]

Finstreet t'as dormi 5 h 8) c'est pas beaucoup :lol:

 

[finstreet]

Oui oui j'ai cliqué sur index sur la colonne, et je ne vois pas de suite le résultat


EDIT : là j'ai indexé le champ et c'est ultra RAPIDE : merci les gars


Si c'est bien d'indexer pourquoi ne pas indexer tous les champs ?

parce que indexer une ou deux colonnes, ca augmente la vitesse... indexer + ca la ralentit car ta base devient de plus en plus grosse

Chaque index double ta base... je simplifie mais c l'ordre de grandeur

ps : en fait couché à 9h levé à 16h lol

 

[onlylove]

Ok super j'ai compris le truc.