Temps De R

mikael2235 · le 13 décembre 2011

Bonjour à tous,

J'ai hébergé sur mon Ds210j, une base de données, une page web en php.

Sur cette page web, j'ai environ 11 requetes vers ma base MySQL, qui renvoie chacune un résultat.

Il faut 63 secondes pour charger ma page, voir même bien plus, plusieurs minutes (à distance), mais même en local, c'est trés long.

Au moment du chargement de la page, la mémoire est environ à 40%, et le processeur 90/100%.

Est-ce normal ? Qu'en pensez-vous ?

Est-ce que le proc. du Ds210j est trop juste pour ça ?

Merci.

Modifié le 13 décembre 2011 par mikael2235

PiwiLAbruti · le 13 décembre 2011

Est-ce normal ? Qu'en pensez-vous ?

Est-ce que le proc. du Ds210j est trop juste pour ça ?

Tout dépend de la volumétrie des tables, de leurs indexes respectifs, et de la façon dont sont rédigées les requêtes que tu exécutes.

Pour résumer, le problème ne vient peut-être pas du NAS mais de l'optimisation de la base de données et des requêtes.

Une requête avec des jointures mal ordonnées peut facilement multiplier le temps d'exécution par 10 sur des tables volumineuses.

PatrickH · le 13 décembre 2011

Alors difficile de répondre, cela va dépendre tu type de requête sql de la taille de la base de donnée et de ce qu'est censé renvoyer ces différentes requêtes. J'ai deux sites avec Joomla et un avec Mediawiki sur mon DS110j et cela fonctionne relativement bien et les 3 utilisent la base MySQL

Grrr: grillé par Piwi....

Patrick

mikael2235 · le 13 décembre 2011

Merci pour vos réponses.

Je n'ai pourtant pas de jointures dans mes requetes. Ce sont des requetes assez simple du type :

SELECT ... , ... FROM ... WHERE ... = ... AND ... = ... ORDER BY ... DESC LIMIT1

J'ai une table qui a environ 300 000 enregistrements. (table qui enregistre mes valeurs météo).

Est-ce que c'est cela qui pose problème ?

PiwiLAbruti · le 13 décembre 2011

Ça ne pose pas de problème, mais ça explique pourquoi c'est lent.

Il faut créer des indexes pertinents (trop d'indexes risque de ralentir l'exécution) sur les champs apparaissant dans les clauses WHERE afin d'améliorer le temps de réponse.

Je suppose que s'il s'agit de données météo, tu dois filtrer sur un intervalle de temps (du type les dernière 24 heures). Dans ce cas il faut commencer par créer un index sur le champ date/heure et voir si les performances s'améliorent.

Mesure aussi le temps d'exécution en enlevant la clause ORDER BY. C'est très gourmand, surtout si le tri se fait sur un champ non indexé.

mikael2235 · le 13 décembre 2011

alors je fais des tests, pour afficher le code suivant, réduit à une requete, il faut 11 secondes :

Mon where porte sur le num de capteur et le type de données, et dans cette page je fais un ORDER BY ... DESC LIMIT1.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<?php

//Connexion database

include("mapage.php");

?>

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

  <title>Météo</title>


  <!-- CSS FILE-->

  <link href="design.css" rel="stylesheet" type="text/css" media="screen"/>

</head>

<body>

  <font size ="2" face="Verdana,Arial,Helvetica,Sans Serif">

  <p align="center" /><img src="banniere_meteo.png" width="898" height="113" alt="domloup" title="domloup" /><br />


  <br />

  <fieldset>

	<?php

	// requete temp intérieure

	$sql = "SELECT valeur_mesure, timestamp_mesure FROM releves WHERE id_capteur='22' AND type_mesure='gust' ORDER BY timestamp_mesure DESC LIMIT 1";

	$req = mysql_query($sql) or die('Erreur SQL !<br>'.$sql.'<br>'.mysql_error());

	while($data = mysql_fetch_assoc($req))

	 {

	 echo $data['valeur_mesure']*3.6;

	 }

	?>

  </fieldset>

</font>

</body>

</html>

En enlevant le order By , il me faut toujours 11 secondes.

Par contre, je n'utilise pas les index, je ne connais pas.

Modifié le 13 décembre 2011 par mikael2235

mikael2235 · le 13 décembre 2011

J'ai mis mes 2 champs id_capteur, et type_mesure en index, j'ai l'impression que ça a améliorer un peu (diviser par 2 le temps de chargement), mais ça reste encore long.

PiwiLAbruti · le 14 décembre 2011

Un peu de lecture pour mieux comprendre les indexes : http://www.siteduzero.com/tutoriel-3-482339-index.html

mikael2235 · le 15 décembre 2011

Après suppression de 310758 enregistrements, il me faut 4 secondes pour charger ma page...

Le problème vient bien du nombre d'enregistrements.

o dako · le 20 décembre 2011

Ben je dirais plutôt que le problème vient des capacités de ton serveur.

Je viens de lire ton topic et côté SQL, tu es arrivé à peu près au bout du possible on dirait.

J'ai eu un ds207+, une config plus ou moins équivalente, et avec 128 Mo de RAM, faut pas rêver sur des tables de taille honorable.

Par comparaison, j'ai une application qui tournait sur le ds207+ en 7h30 (de requêtes SQL).

J'ai changé pour un ds1511+ et je suis passé à 30' de temps d'exécution.

mikael2235 · le 22 janvier 2012

Mon problème recommence, je n'ai pourtant que 31000 enregistrements dans ma table.

Il me faut 63 secondes pour charger ma page, et quand je veux y accéder avec le iphone impossible, j'ai le message suivant :

safari n'a pas pu ouvrir la page car le serveur ne répondait plus

J'ai pourtant rajouté dans ma page web : set_time_limit(), mais c'est idem.

J'ai changé pour un ds1511+ et je suis passé à 30' de temps d'exécution.

Le prix du 1511+ n'est pas non plus le même que celui d'un Ds210j...

marcien · le 22 janvier 2012

Ton index, il faut le creer sur un bon ordre de champ : du + discrimiment (celui qui a le + de valeurs distinct) vers celui qui a le moins de valeur distinct... Si en plus, les 1er champs peuvent avoir des valeurs croissantes, comme une date, c'est encore mieux...

Mais le pb de faire des INSERT, puis des DELETE, puis des INSERT..., c'est que dans l'index et la table , il y a des zone sans info (comme des trous) !

Faut optimiser ! Regarde :

http://dev.mysql.com/doc/refman/5.0/fr/analyze-table.html

http://dev.mysql.com/doc/refman/5.0/fr/optimize-table.html

Lya72 · le 27 février 2012

Bonsoir,

Je fais un UP sur ce sujet car je trouve qu'il le mérite.

A mon avis, le paramétrage de MySQL ne semble pas optimisé, en rapport avec la configuration matérielle du Synology.

Je m'explique :

Etant l'heureux possesseur de 2 Synology différents, j'ai pu constater que le paramétrage de MySQL était identique sur les 2 !!

Les machines :

DS207+ CPU : 500Mhz / RAM : 128 Mo

DS211+ CPU : 1.6Ghz / RAM : 512 Mo

Pour une requête sur les données journalières extraites d'une base de 500 000 enregistrements, il faut près de 20 secondes au DS207+ et 9 secondes au DS211+.

Bien sûr, un index est positionné, sur le champ Date/Heure de sélection.

Pour moi, le gain de temps entre les deux Synologys est seulement un gain relatif à la puissance processeur.

Pour la mémoire, sur les 2 machines, MySQLD ne consomme QUE 16 Mo !!

Il y a donc bien une optimisation possible, au moins sur le DS 211+, car à mon sens, le temps d'attente est lié au parcours des tables sur disque car celles-ci ne sont pas montées en mémoire.

Il faudrait monter les tables en mémoire en réservant environ 100 Mo pour MySQL (- de 20% des 512 Mo de RAM du DS211+).

==> Qui a déjà modifié les paramètres MySQL de son Synology et à quel niveau ??

==> Merci pour vos contributions.

Yann

Modifié le 27 février 2012 par Lya72

Patrick21 · le 27 février 2012

Bonsoir

on peut modifier les valeurs dans /usr/syno/etc/php.ini

memory_limit = 256M ; Maximum amount of memory a script may consume (128MB)

Patrick

Lya72 · le 27 février 2012

Bonsoir Patrick et merci pour ce premier retour.

A mon sens, les paramètres que tu indiques sont relatifs à PHP et non à MySQL.

Pour toi, ces deux paramètres permettraient d'augmenter la zone mémoire accordée à MySQL ???

Yann

Lya72 · le 1 mai 2012

Bonsoir,

Ayant effectué quelques optimisations sur les paramètres MySQL de mes Synology, j'avais pu constater une petite amélioration.

Par contre,

ces modifications touchant aux paramètres systèmes du Synology étaient effacées lors des mise à jour.
Mes données croissant de jour en jour, il fallait reprendre le raisonnement à la base, ou changer de Synology chaque année !!

Soit c'était la progression technique qui me permettait de résister à la croissance des données, soit j'optimisais leur extraction.

J'ai découvert dans mes recherches qu'une table fréquemment mise à jour (INSERT fréquents) ne reste pas dans le cache.

Or toutes mes données sont mises à jour chaque minute (relevés station météo, voltage des batteries solaires et téléInfo EDF).

De plus, j'ai constaté que la majorité de mes requêtes s’effectuaient sur les données de la veille ou du jour en cours (les fameux superbes graphiques temps réels).

Donc, il me fallait interroger des tables ne comportant que ces données !!!!!!

Comment générer celles-ci en temps réel ?

==> Les Triggers MySQL permettent cela.

J'ai donc mis en place des tables doublons de mes tables historiques (préfixées par instant_xxxxx)

J'ai ensuite mis en place des triggers dans MySQL :

Lors de chaque INSERT effectué sur la table historique, la ligne de données est dupliquée dans la table instant_xxxxx.

Ensuite avec le scheduler MySQL, à chaque nouvelle journée, je détruis les enregistrements de l'avant-veille.

Au final, mes tables instant_xxxx ne comportent que les enregistrements du jour et de la veille, soit au maximum 2880 enregistrements, au lieu de plus de 600 000 enregistrements sur mes tables historiques.

Sur mon DS207+, les graphiques temps réel s'affichent en moins de 4 secondes au lieu de 19 secondes avant (divisé par 4).

SUPER !!!

PS : l'explication est peut-être complexe, mais c'est très simple à mettre en oeuvre et cela résiste aux upgrades.

Modifié le 1 mai 2012 par Lya72

Connexion

Temps De R

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Rejoindre la conversation

Qui est en ligne 12 membres, 0 anonyme, 274 invités (Afficher la liste complète)

Contributeurs populaires

Information importante