ce coup ci je suis vraiment dans la m....

[caro]

je suis coincée pour de bon les gars,
vu qu'on a aucune expérience réelle dans les bases de données mon patron m'a demandé de trouver de l'aide même si il faut payer (enfin carte blanche ).

dès qu'on dépasse les 30 à 35 connectés sur notre mini forum (concu par nous mêmes) ca prend 100% des ressources CPU et tout est bloqué, on ne peut même plus accéder aux pages html du site !

quelqu'un pourrait il nous aider?
merci de me contacter soit ici soit par message privé.
carole


ps : on est hébergé chez Amen avec un serveur privé virtuozzo avec environ 150 Mo de mémoire.
je commence à me demander si ca vient pas carément du serveur qui est pas assez puissant ou alors il ne faut peut être pas que je mette la base de données et les fichiers sur le même serveur ?

 

[caro]

je vais quand même mettre les infos de la base :

1) STRUCTURE DE LA BASE :

CREATE TABLE `forum` (
`numero` mediumint(6) unsigned NOT NULL default '0',
`reponse` mediumint(6) unsigned NOT NULL default '0',
`nbreponse` mediumint(6) unsigned NOT NULL default '0',
`date` datetime NOT NULL default '0000-00-00 00:00:00',
`datereponse` datetime NOT NULL default '0000-00-00 00:00:00',
`categorie` varchar(20) NOT NULL default '',
`pseudo` varchar(15) NOT NULL default '',
`titre` varchar(40) NOT NULL default '',
`message` text NOT NULL,
`photo` varchar(13) NOT NULL default '',
`email` varchar(30) NOT NULL default '',
`adresseip` varchar(15) NOT NULL default '',
`blocage` char(3) NOT NULL default '',
`reponsepseudo` varchar(15) NOT NULL default '',
KEY `categorie` (`categorie`),
KEY `numero` (`numero`),
KEY `reponse` (`reponse`)
) TYPE=MyISAM;

il y a un index sur les champs :
- categorie
- numero
- reponse


2) REQUETE PRINCIPALE POUR AFFICHER LISTE DES DISCUSSIONS :

$table=mysql_query("SELECT * FROM forum WHERE categorie='principal' and reponse='0' ORDER BY datereponse DESC LIMIT $a,50");
while($ligne=mysql_fetch_object($table)) {affiche titre+date+pseudo}

3) REQUETE SECONDAIRE POUR AFFICHER LES MESSAGES :

$table=mysql_query("SELECT * FROM forum WHERE numero='$numero' ORDER BY reponse ASC LIMIT $a,20");
while($ligne=mysql_fetch_object($table)) {affiche messages d'une discussion}

c'est la requete principale qui affiche la liste des discussions qui rame vraiment par rapport à l'autre.
merci merci merci merci merci de votre aide et patience :wink:

 

[moutyk]

Salut,
Pas terrible le SELECT * tu peux surement faire mieux de se coté la

Ton serveur est peut etre limite ? Toute fois 30 visiteurs simultanés c'est pas enorme du tout.

J'utilise cette requête depuis quelques temps, elle me pose aucun problème je sais pas si ca pourra t'aider

La fonction mysql_free_result peut etre interessant dans ton cas ?!

Je suis loin d'être un spécialiste du php toute fois je prend le risque de te proposer quelque chose à adapter :wink:

// on créer la data SQL et on l'envoie 
$sql = "SELECT id_membre,quand,sexe,nom,prenom FROM membre ORDER BY id_membre DESC limit 20";  

// on envoie la data 
$req = mysql_query($sql) or die('Erreur SQL !<br>'.$sql.'<br>'.mysql_error()); 

// on fait une boucle qui va faire un tour pour chaque enregistrements 
while($data = mysql_fetch_array($req)) 
    { 
    // on affiche les informations de l'enregistrements en cours avec data si on le souhaite';
     echo ''''.$data['sexe'].' '.$data['nom'].' '.$data['prenom'].' -';
} 

//on libère la mémoire
mysql_free_result($req);

// on ferme la connexion à mysql 
mysql_close($db);

 

[Gralon]

index ton champs datereponse
et augmente ta ram aussi, 150 Mo c'est pas beaucoup quand même.

tu es sûr qu'il n'y a pas autre chose sur ta page qui augmente la charge ?

 

[Moffen]

Salut,
Tu devrais essayer avec une clé primaire sur chacune des table ou c'est possible d'en trouver une ...
ex table forum si numero est unique faire :
ALTER TABLE `forum` DROP PRIMARY KEY, ADD PRIMARY KEY(`numero`)
(et ensuite déclarer les clé secondaires correspondantes dans les autres tables)

 

[olivieri]

Oui, et retirer l'indexation sur categorie qui est un string, ca doit pas mal ralentir ca ...

 

[herisson]

Salut,

je te conseille de gérer les catégories avec une autre Table avec un identifiant qui soit numérique, et de créer dans ta table "forum" une clé étrangère genre "ID_CATEGORIE" -->tu pourras ainsi éviter un tri + un index sur un champ varchar (le champ catégorie) qui consomme bcp de ressource , comme l'a dit olivieri

 

[caro]

je vous remercie ENORMEMENT les gars :wink:

je vais appliquer vos conseils :
1/ SELECT quelques champs au lieu de *
2/ indexer mon champs "datereponse"
3/ modifier champs "categorie" et le passer en numérique
4/ mettre un index sur categorie

encore mille merci
carole

 

[pipologue]

Le virtuozzo de Amen est pas fait pour des sites ayant autant de visiteurs en même temps (j'imagine qu'au total, ça chiffre en milliers/visiteurs/j).

Amen m'a avoué au téléphone que ce qui est présenté comme un dédié ne l'est pas vraiment (techniquement c'est du mutualisé sur lequel on met un système d'exploitation configurable par client), on commence à 64mo de ram dédiée avec le plan de base (pas officiellement) et ça augmente par tranche de 64mo quand vous augmentez l'espace disque.

La solution : un dédié puissant (et faisant quand même tout ce qui est dit au dessus).

 

[rebirth]

je suis coincée pour de bon les gars,
vu qu'on a aucune expérience réelle dans les bases de données mon patron m'a demandé de trouver de l'aide même si il faut payer (enfin carte blanche ).

dès qu'on dépasse les 30 à 35 connectés sur notre mini forum (concu par nous mêmes) ca prend 100% des ressources CPU et tout est bloqué, on ne peut même plus accéder aux pages html du site !

quelqu'un pourrait il nous aider?
merci de me contacter soit ici soit par message privé.
carole


ps : on est hébergé chez Amen avec un serveur privé virtuozzo de 1 Go et environ 150 Mo de mémoire et la base de données est installé sur le serveur interne.

je commence à me demander si ca vient pas carément du serveur qui est pas assez puissant ou alors il ne faut peut être pas que je mette la base de données et les fichiers sur le même serveur ?

dois je prendre un serveur que pour la base de données ?
le virtuozzo d'Amen n'est il pas suffisant ? autant ca vient pas de notre code source.

Tu peux essayer memcached, ca supprimera une bonne partie de tes acces a la base, tout restera en RAM.
http://www.danga.com/memcached/

Mais il serait tout de meme peut-etre temps de passer sur un vrai serveur aussi....

 

[caro]

après avoir suivi vos conseils je viens de trouver ce qui coince je pense.

c'est le ORDER qui fait ramer à fond !

1) si je lance :
SELECT * FROM `forum` WHERE categorie='identifications' and reponse='0' ORDER BY datereponse DESC LIMIT 0,50
ca met 0.31 secondes

2) si je mets pas le ORDER :
SELECT * FROM `forum` WHERE categorie='identifications' and reponse='0' LIMIT 0,50
ca met 0.002 secondes

je constate que ca rame car une fois la recherche effectuée la base rame car elle a du mal à trier les 10 000 messages du champs qu'elle a récupéré.

y a t'il une astuce pour ce ORDER ?

merci beaucoup
carole

 

[rebirth]

y a t'il une astuce pour ce ORDER ?

Un tri ca reste tout de meme un peu long et "CPU-intensive"....surtout pour 10000 elements...

Le seul vrai moyen de tuer tout ca, c'est d'employer un systeme de cache...

Tu n'auras plus beaucoup de CPU / SQL de bouffé....

 

[caro]

merci beaucoup les gars pour vos conseils,
j'ai tout optimisé et je viens de confirmer ce que dit Rebirth,
j'ai testé la meme requete sur ma base et sur une autre base et le temps de réponse est incroyablement plus bas sur une autre base.
chez moi : 0.25 secondes
autre base : 0.02 secondes
soit 10 fois moins !!

quelqu'un pourrait donc me conseiller une adresse pour prendre un bon serveur ?
chez amen c'est la merde ! ils me font acheter sans cesse des mémoires pour rien.

encore merci à tous, vraiement
carole

 

[loulo]

Pour un bon serveur, http://www.sivit.fr, si vous avez une expérience de l'administration serveur, même si ce n'est pas le cas avec les tutos du forum sivit, cela est simple.
Ce sont des serveurs qui permettent d'en faire ce que tu veux, mais ça demande un minimum de connaissances.

 

[GAMING ZONE]

SInon, sans changer de serveur, il y a possibilté d'arranger le temps de reponse, mais comme tu as carte blanche, on fait quoi
Serieux, il y a une bonne possibilité qui libera pas mal de ressource, par contre, il faut revoir une bonne partie du programme ...
Bien sur , sans changer d'hebergement , ce qui evitera certains petits problemes liés au referencement ...

 

[rebirth]

quelqu'un pourrait donc me conseiller une adresse pour prendre un bon serveur ?

La question est surtout....
Quel est ton budget ?

 

[nataz]

Si tu recherche un fournisseur de confiance va faire un tour sur www.infomaniak.ch

en gros pour 120 € / an (je crois qu'il y a une action de noel pour 60€ la première année) tu obtiens 1.5Go d'espace, 80 Go de trafic mensuel, 1200 adresses email, 15 bases mySQL complètes, hit illimités, toutes les options PHP,MySQL,ASP,Flash,etc.

Je fais tourner de très gros scripts PHP/MySQL régulièrement depuis 3 ans et je n'ai jamais atteint les limites des bécanes.

 

[pipologue]

Prend un dédié chez Magic... ils s'occupent des mises à jour, te propose d'administrer ton dédié à la demande si tu en as besoin...

 

[GAMING ZONE]

Caro, toujours dans la m..... ?
Sinon je te conseil Free.fr si c'est un site a but non commercial, c'est gratuit, et cela fonctionne correctement

 

[Blini]

Une autre idée...
Comme ta requête doit récupérer les 50 denières interventions (les 50 ayant les datereponse les plus récents), il pourrait être intéressant de créer une seconde table (deux champs: datereponse et un champ qui contient la valeur de la clé primaire sur ta table principale). Appelons-la "RECENT".
Quand tu insères un record dans la table principale, tu en profites aussi pour:
- copter le nb d'élements de RECENT
- si ce nombre est supérieur à 50, virer les records avec datereponse les plus vieux
- insérer dans RECENT un record avec la datereponse et la valeur cleprimaire de ta table principale

Puis quand tu as besoin des 50 records les plus récents, il suffit de récupérer tous les records de RECENT, et récupérer les records correspondants (grâce au deuxième champ qui contient la clé primaire) de la table principale. Ainsi, tu n'as pas de order by à faire.
Et les requêtes supplémentaires que tu fais à l'insertion dans la table principale (les étapes décrites ci-dessus), à mon avis, c'est pas grave si ça prend un peu de temps.

Bon, maintenant, je sais pas ce que ça vaut de faire 2 requêtes sans "order by" au lieu d'une seule avec.