Discussion :

[dev14]

Bonjour et bonne année,

j'ai des requêtes lourdes qui ne s'affichent plus depuis plus d'un an sur lesquelles je m'étais fait une raison, avec la page d'erreur 500.

J'ai déjà optimisé à fond, mais le problème est le volume d'une table en BDD, 200 mille enregistrements d'une vingtaine de champs. C'est pas beaucoup pourtant quand je vois d'autres volumes de 500 mille voir plus dans d'autres sujets.

En tout cas moi ça passe plus. Et donc je voudrais savoir, quel paramètre on peut changer dans les fichiers de conf, comme le my.ini, pour augmenter les capacités de gestion de requêtes?

Merci

[rawsrc]

Salut,

avant d'aller tripatouiller la configuration, je t'invite à poser des index sur les colonnes des tables utilisées dans les requêtes.
Parce que 200 000 enregistrements sur 20 colonnes c'est vraiment rien mais alors rien du tout pour un moteur de base de données.

[sabotage]

Il faudrait déjà connaitre la vraie erreur qui se produit : "500" est une erreur générique affichée par le serveur web.
Consulte tes logs PHP.

[dev14]

merci et désolé de répondre tardivement, je ne pensais pas avoir de réponses si rapides,

je n'ai rien dans mon fichier de logs,

en fait j'ai certes que 200 000 enregistrements, j'ai déjà des index, mais pour ma requête, je n'ai pas de condition where, " j'affiche tout ", plus précisément, je dois récupérer l'ensemble de mes enregistrements, des calculs sont faits, puis tout est synthétisé, mais je dois tout récupérer. Et ça ne lui plait pas la récupération d'environ 200 mille enregistrements. Existe-t-il un moyen d'optimiser à ce niveau?

[sabotage]

Il est quand même très probable que tu atteignes une limite de temps d'execution ou de mémoire et donc il doit y avoir une erreur PHP.
Donc soit ton serveur ni ne log, ni n'affiche les erreurs, soit tu ne regardes pas le bon log.

[dev14]

les logs que je prends sont dans la console, ou bien directement sur wamp/logs/

rien à la date et heure d'exécution du script pour le php_error.log, ni pour le apache_error.log, et sur le access.log j'ai ceci (synthétisé) :

::1 - - [11/Jan/2016:13:00:14 +0100] "GET /mywebsite/ HTTP/1.1" 200 1132

[ css, jpg, js, ... ]

::1 - - [11/Jan/2016:13:00:14 +0100] "GET /favicon.ico HTTP/1.1" 200 202575
::1 - - [11/Jan/2016:13:00:16 +0100] "POST /mywebsite/ HTTP/1.1" 500 -

[rawsrc]

Salut

Tu peux poster ton script de stats parce-qu'à priori j'aurais tendance à suivre la position du sieur sabotage quand il dit qu'il y a peut-être un problème dans le script.

[kolodz]

J'aurai tendance à vérifier la valeur du timeout serveur.
Celle-ci peut-être modifier / via la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set_time_limit (0);

http://php.net/manual/fr/function.set-time-limit.php

De même que la valeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// Affichage du temps maximal d'exécution
echo ini_get('max_execution_time');
 
ini_set('max_execution_time', 300); //300 seconds = 5 minutes
ini_set('max_execution_time', 0); //0=NOLIMIT

Attention, il ne faut pas utiliser du "no limit" de manière systématique. Au risque de surcharger le serveur sur des requêtes qui aurait du s'arrêter.

Cordialement,
Patrick Kolodziejczyk.

[dev14]

Hélas toujours pas, ça reste en suspend, j'ouvre une petite parenthèse concernant les index pour d'autres requêtes, y a t il moyen de les faire fonctionner avec la clause like dont les premiers caractères sont inconnus? Par exemple si champ1 est en index, et que j'ai une requête de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
select * from matable where champ1 like '%test%'; #fonctionne pas
select * from matable where champ1 like '%test'; #fonctionne pas
select * from matable where champ1 like 'test%'; #fonctionne

J'ai mis fonctionne / fonctionne pas en utilisant le explain devant la requête.

[kolodz]

Pour ton problème principale, essai de forcer l’arrêter/retour de la part du serveur (Violemment si besoin pour debugger). Peut-être que tu peux fractionné ton traitement, où réaliser celui-ci en asynchrone.

Pour ta question annexe, cela est totalement normale. Tu peux lire cette article par rapport à ce sujet :
Indexer les filtres LIKE
En résumé, cela est dû à la structure des index, ceux-ci sont globalement des liste triées. Si ton caractère inconnu est en première position, alors l'index n'est pas efficace. Car la base de données ne peux pas profité du trie pour facilité la recherche.

Cordialement,
Patrick Kolodziejczyk.

[dev14]

je vais étudier la question, merci pour vos réponses