Je déploie actuellement une application ASP.Net 2.0 qui utilise une base de données MySQL sur un serveur FreeBSD par le biais d’ODBC.
Un des pages effectue pas mal de requêtes de type SELECT et apperement l’execution de cette page fait planter le serveur MySQL. D’aprés mes expériences passées c’est surtout l’établissement de la connection avec la base de données qui consomme du temps et des ressources, donc je n’établis la connection qu’une seule fois par an.
Est-ce qu’il y a d’autres techniques pour améliorer la vitesse des requetes ?
type de requetes (jointures, unions [f34r], recherches fulltext…)
InnoDB ou pas ?
BinLog ou pas ?
ton “MySQL qui plante” ce serait pas un memory full ? Vérifie dans /var/log/messages.
Mais comme point de départ :
tu es sûr d’avoir “optimisé” tes tables -> souvent les développeurs pressés et pas très expérimentés oublient les indexes, voire carrément le champ “id” [f34r encore]. Et ça, c’est bête, très bête.
si tu joues avec des grosses tables, tuner MySQL est fortement conseillé (les différents my.cnf fournis dans /usr/local/share/mysql sont un bon début)
as-tu compilé ton MySQL avec support threads ? Si ta FreeBSD est 4.x, il te faudra compiler avec les threads Linux, sinon faudra compiler avec le support natif FreeBSD.
[edit] par contre, meme s’il est souhaitable de gérer des pools de connexions comme avec n’importe quelle application persistante, les connect en MySQL sont super rapides (vu que la base est prévue pour fonctionner avec des langages de script comme le PHP).
Bon deja en ASP.Net, avec n’importe quel “driver” de db digne de ce nom il y a des pool de connection donc c’est pas a toi de te soucier de combien de fois tu appelle .Connect(), ca veut pas dire que tu te connecte physiquement a la db, ca veut juste dire que t’en demande une au pool. Et heu, je pige absoluement pas ce que tu veux dire par “je n’établis la connection qu’une seule fois par an”, ca n’a aucun sens B)
Ensuite ODBC c’est plutot lent. Il vaut mieux utiliser des clients natifs .Net pour chaque base de donnees. ODBC ca va pour depanner sans se prendre la tete, et/ou faire une application rapide ou les performances ne sont pas primordiales, ca arrive souvent, mais si c’est pour faire du gros volume en prod il faut un client natif.
Enfin MySql a qui il arrive de planter plus souvent qu’il devrait… oui… voila quoi…
Maintenant vitesse ou plantu ca a absoluement rien a voir. A part si ce que tu appelles “planter” c’est un timeout au niveau de la couche ODBC, si MySql plante c’est pas en ameliorant la vitesse des “connections” que tu changeras quoi que ce soit au probleme.
Oh le troll B) Sans rentrer dans un gros débat stérile, je n’ai jamais rencontré de soucis de stabilité particulier avec MySQL. Je pense qu’il faut bien distinguer « application qui plante » et « application qui se fait buter par le kernel parce que memory full » [cf les soucis de cafzone sur l’ancien serveur].
C’est du MySQL 5.0, la table est en InnoDB et contient environ une centaine de tables avec 50 000 enregistrements pour les plus grosses tables. Au niveau des requetes, c’est des jointures sur des tables contenant normalement des indexes.
En fait, je m’occupe pas de la base de données MySQL a priori, c’est un autre presta qui s’en occupe (moi je suis aussi ce qu’on pourait appeller un presta du client final) Donc c’est surtout au niveau de l’ASP.Net que je voudrais être sur que c’est optimisé au mieux.
Je vais essayer de voir du côté des drivers natifs, merci pour vos réponses.
Ptain… ca éxiste toujours ce genre de projet, ou t’as un clapin qui design la base de donnée, et un autre qui fait l’appli WEB par dessus… La remise en question ca peut avoir du bon de temps en temps ^^.
Bon désolé pour le ton un peu mauvais, mais c’est vrai que ca m’inquiète franchement.