Discussion :

[lio33]

Bonjour.

J'ai besoin de l'avis de personnes éclairées et avec de l'expérience au sujet d'un problème de performances réseau ou Serveur.

Mon application exploite 5 PC reliés en réseau local 100Mb (dédié) autour d'un serveur Interbase ( Serveur HP Proliant Bi processeur, mais une seule licence serveur pour l'instant, 2Go RAM ECC, RAID 5 SCSCI ULTRA 320 pour la base de données ).

Chaque PC fait tourner une application de test en C qui envoie 10 requêtes par secondes vers le serveur ( chaque requête encadre dans une transaction un appel à une procédure stockée ). Pas beaucoup de paramètres à chaque appel.

Des que je commence à dépasser 3 PC sur ce réseau les applications n'arrivent plus à tenir le rythme des 10 requêtes par seconde.

1) Pensez vous que la ralentissement observable puisse être du au traffic réseau ou au serveur Interbase? (Les procédures ne renvoient qu'un entier en retour d'exécution.)

Sur ce dernier la fenêtre de performances Windows affiche un taux occupation processeur entre 20 et 25% et peu de mémoire utilisée (250Mo).

2) Pensez vous que le serveur Interbase puisse déjà être saturé par ce rythme de requêtes ou est-ce une charge tout à fait gérable pour lui ?

Je compte un peu sur votre expérience pour me donner des pistes ... et reste à votre dispo pour vous fournir des infos supplémentaires si vous le souhaitez.

Merci d'avance


_______________________________
Titre modifié par par yobenzen
Merci de ne pas mettre urgent dans le titre

[qi130]

D'après ce que tu énonces, je vois 2 pistes à suivre pour détecter le point d'engorgement:

1/ le réseau, et + exactement la carte réseau du serveur: il conviendrait peut-être de monitorer ce composant...
Mais je ne parierais pas lourd sur ce point, sauf si les requètes envoyées par les clients font 3 km de long

2/ le périphérique de stockage : mais là, ça devient technique...
Il faudrait en effet corréler la typologie des requètes avec:
- le temps d'accès des (à cause du raid) HD (si il y a écriture)
- le temps d'accès et le % de fragmentation et le déplacement nécessaire de la tête et le nb de secteurs lu sur le disque

en effet, un HD avec beaucoup de mémoire tampon va prendre du temps pour alimenter (charger) ce tampon. Ca veut dire lire beaucoup de secteurs physiques contigüs (car le HD n'a pas l'intelligence de connaitre le contenu d'un secteur pour savoir s'il contient la suite logique du secteur précédent).

Ainsi, si les requètes ne trouvent pas leur réponse dans le tampon, le HD devra le vider/recharger, ce qui prend du temps...

Un autre point serait à vérifier: les transactions ( oui, encore ). Je ne sais pas s'il existe un "règlage" qui permette de se satisfaire d'un niveau de fraicheur des données légèrement dégradé (et qui n'obligerait donc pas une lecture physique du disque)

[lio33]

Merci d'avoir pris le temps de jeter un oeil à ma demande et d'y avoir répondu.

J'avais des doutes quant au fait que le serveur ne puisse suivre le rythme demandé. Ce dernier n'est en rien la cause de la lenteur.

Le réseau n'y est pour rien non plus. La cause était due à un module de notre application qui scrute périodiquement le réseau pour détecter des pertes de communication. Un fois ce module inactif, les performances reviennent ( faible charge CPU des clients, et les requêtes passent toutes ).

Par contre j'ai pu vérifier que lors de l'appel des procédures stockées, je mettais en oeuvre une fonction DBRefrechParam() de Labwindows CVI ( mon env de développement ). Cette fonction permet je pense de retrouver le mapping des parametres de la procédure stockée avant son appel. Cette fonction génère beaucoup de traffic et surtout une charge importante du serveur interbase (25%).
Aprés modification des fonctions d'appel et l'utilisation de fonctions DBCreateParam en lieu et place de DBRefreshParam, la charge du serveur tombe entre 1 et 5% max

Désormais tout roule et le serveur tient bien la route ( pour info sur mon portable, en local, Ib tient 100 requetes par secondes sans pb. ).

Comme quoi ... il faut pas grand chose pour dégrader les performances d'un serveur de bases de données !

Merci encore.