Linux MSSQL et lenteur

[la_bouleaouane]

Bonjour,
je suis tombé sur un problème que je n'arrive pas à expliquer et j'aurais besoin de vos lumières...
je possède 2 serveurs 1 web et 1 sql serveur qui constituent un serveur web
le web (linux) attaque la bdd via mssql (freetds)
tout se passe bien dans le meilleur des mondes sauf dans un cas, en effet plus mes requêtes sont longues plus les réponses du serveur le sont, vous allez me dire c'est normal mais je n'en ai pas l'impression.
par exemple un select sur 2 champs avec genre un in (.........) si le in fait plus de 1000 caractères la réponse revient quelques secondes plus tard (une centaine de ligne) alors que sont temps de réponse en local sont instantanées...
j'ai pensé dans un premier temps a un souci de connexion entre les serveurs mais ce n'est pas ca.
de plus c'est exponentiel genre 500 lignes 10 sec , 1000 ligne 30sec 2000 80 etc... alors que la même requête en local est retournée instantanément.
Ca me donne l'impression d'être mis dans un buffer et de rester en attente...
Pour info si je mets ma grosse requête dans une procedure et que j'appelle celle-ci via mon script web le retour est instantanée...
dès que je transfert une grosse quantité de datas ca tombe en fait.

merci a vous

Franck

[elsuket]

Bonjour,

tout se passe bien dans le meilleur des mondes sauf dans un cas, en effet plus mes requêtes sont longues plus les réponses du serveur le sont, vous allez me dire c'est normal mais je n'en ai pas l'impression.

Non, ce n'est pas normal. SGBDR n'est pas synonyme de lenteur.

par exemple un select sur 2 champs avec genre un in (.........) si le in fait plus de 1000 caractères la réponse revient quelques secondes plus tard (une centaine de ligne) alors que sont temps de réponse en local sont instantanées...
j'ai pensé dans un premier temps a un souci de connexion entre les serveurs mais ce n'est pas ca.
de plus c'est exponentiel genre 500 lignes 10 sec , 1000 ligne 30sec 2000 80 etc... alors que la même requête en local est retournée instantanément.
Ca me donne l'impression d'être mis dans un buffer et de rester en attente...
Pour info si je mets ma grosse requête dans une procedure et que j'appelle celle-ci via mon script web le retour est instantanée...

En fait vous faites passer votre chaîne de requête à travers le réseau ... or les réseau est ce qu'il y a de plus lent dans une infrastructure, après les disques mécaniques ...

Ensuite il faut que SQL Server parse le IN, le trie, ce qui prend du temps CPU, et si le nombre de valeurs est grand, peut prendre plusieurs secondes ...

En supposant que vous n'utilisez pas EXEC sp_executesql, à chaque fois que vous soumettez une requête, celle-ci doit d'abord être comparée à toutes celles qui sont déjà dans le cache et dont les filtres sont "en dur" : vous voyez le boulot.
Ensuite, comme la requête n'est pas trouvée, elle doit être compilée, puis exécutée, et enfin le résultat doit passer de nouveau à travers le réseau.
Vous le dites vous même : quand vous passez par une procédure stockée le résultat revient dans un temps correct.

Vous rejoignez en cela l'idée des SGBDR dits "épais", qui vous évitent ce tracas.

D'autre part, j'évoque ici les raisons pour lesquelles il est bien mieux d'utiliser des procédures stockées.

Enfin si vous voulez voir où se situe la lenteur, vous pouvez utiliser les statistiques du client

@++