Vous n'êtes pas identifié(e).
Bonjour,
Nous sommes actuellement en train de développer une application .Net en C#, basée sur une base de données PostGre.
La base de données contient actuellement 120 tables, pèse actuellement 60 MO (phase de test) et nous utilisons des images pour stocker des logos, des schémas ou des photos.
Les images sont stockées au format "bytea".
A partir de l'application nous récupérons les images dans des Large Object.
Nous utilisons des index sur les clés primaires et les clés externes.
Nous observons de grandes différences de performances entre :
- l'utilisation d'une base de données "locale", hébergée sur un serveur en interne
- l'utilisation d'une base de données hébergée sur le serveur OVH (bande passante garantie de 200 Mb/S)
Le temps d'affichage de certains écrans passe d'un rapport de 1 à 8, et cela se produit principalement sur les écrans contenant des images ou un éditeur développé en WPF et intégré à l'application.
Par exemple, nous affichons une liste de 700 éléments, contenant des logos et des drapeaux qui prends 2 secondes en local et 1minute30 sur le serveur OVH.
Pourtant chaque image est une miniature de 16x16 ou 20x20 et n'excède pas 1 à 2 KO.
Au niveau du serveur, il s'agit d'un Intel Xeon E5405 64bits, avec 2 processeurs à 2 GHz, disposant de 16 Go de RAM.
Il tourne sous Windows 2008 R2 Standard.
Auriez vous des idées ou des conseils d'optimisation du serveur Postgre?
J'ai pour l'instant modifié les réglages de Postgresql.conf en me basant sur ceux fournis dans cette page "http://infodecisionnel.com/bdd/optimisa … ostgresql/".
Est ce adapté à mon cas?
Que puis je modifié d'autre?
Merci,
Hors ligne
Bonjour,
Pourquoi pensez-vous que c'est le serveur de base de données qui pose problème? (vu les éléments, cela me semble certainement pas la première hypothèse à envisager, mais je ne connais pas votre application.)
Où est la partie métier de votre application (en local? sur le même serveur que la base de données? Sur un autre serveur chez OVH???)
Comment récupérez-vous les 700 images au niveau de l'application? (une par une ou par un seul select?)
Flo
Hors ligne
Je suis d'accord avec Florence. Rien ne montre que le problème provient des performances de PostgreSQL. Du coup, vos modifications de la configuration peuvent apporter une amélioration, mais c'est loin d'être certain.
Il vaudrait mieux préciser le problème, ie trouver si les requêtes sont plus lentes par exemple. Et si oui, lesquels.
Guillaume.
Hors ligne
Bonjour,
Nous avons exactement le même problème, et il semble effectivement que ce soit Postgre qui limite :
Développement d'une appli VB.net, bases PostgreSQL.
Nous observons le trafic réseau du serveur dédié hébergé chez OVH.
- Pendant une requête Postgre, le trafic réseau ne monte pas à plus de 3O kO/s
- Si on effectue un test de débit (via degrouptest par exemple), le débit grimpe à 95 Mb/s, ce qui correspond à la bande passante assignée par OVH.
Et si le test de débit est fait pendant l'exécution de la requête, on voit clairement que le débit sortant du serveur augmente en flèche.
Il nous semble donc que ce soit Postgre qui soit limité.
Quelqu'un a-t-il trouvé la solution ?
Merci de vos réponses
Babourius
Hors ligne
Bonjour,
Ce serait très étonnant que cela provienne de PostgreSQL. Pour information, il est utilisé dans de très nombreux gros sites, qui n'ont évidemment pas les 'symptômes' que vous décrivez, probablement parce qu'ils sont architecturés correctement.
Il est tout à fait possible, suivant ce que vous demandez au serveur, que le débit ne monte pas à plus de 30ko/s. Sur quelle requête ? Une seule requête ou une série de requêtes exécutées consécutivement ?
Le serveur PostgreSQL et le client sont ils sur le même réseau ?
Vous ne souffrez probablement pas d'un problème de débit mais d'un problème de latence.
Marc.
Hors ligne
Bonjour,
Nous ne sommes pas sur le même réseau : serveur hébergé chez OVH, client dans nos bureaux. Accès via le net.
Ceci se produit sur toutes les requetes, de laplus simple (select * from matable) à la plus compliquée (jointures entre plusieurs tables)
Si nous lançons la requete "en local", c'est à dire en prenant la main à distance sur le serveur et en l'exécutant dans postgresql, le temps de réponse est correct. donc a priori cela ne vient pas de postgres "seul".
Par contre quand nous lançons la requete à distance, nous constatons que la bande passante est loin d'être à son maximum.
Nous sommes sous Windows Serveur 2008 R2 Web edition. Savez-vous si un paramétrage de Windows permet de jouer sur la bande passante en fonction des logiciels...
Pour info, le ping du serveur depuis nos bureaux est très rapide.
Merci de vos réponses.
Babourius
Hors ligne
- Aucun SGBD n'est conçu pour être utilisé sur un WAN. Les protocoles ne sont pas faits pour cela.
- La complexité de la requête n'a pas d'importance, c'est le nombre d'aller/retour entre le client et le serveur qui pose problème (le protocole donc)
- Le ping est très rapide ? Qu'appelez vout très rapide ? Sur un LAN, le ping sera de l'ordre de quelques microsecondes. Ça m'étonnerait que vous ayez quoi que soit de proche sur internet.
Marc.
Hors ligne
Marc,
Merci de votre réponse.
Dans ce cas, pensez-vous que si nous créons un webservice sur le serveur dédié celà ira plus vite ?
J'explique : nous appelons les fonctions du webservice, qui interroge le SGBD localement (car sur la même machine), puis nous renvoie la réponse (fichier XML)
Votre avis ?
Cordialement,
Babourius
Hors ligne
Si le webservice permet de n'avoir qu'un seul dialogue client/serveur entre le local et le distant, au lieu de 50 requêtes, oui, ça peut être une solution. Parce que je pense que la cause initiale de votre problème n'est pas le débit d'une requête unitaire, mais le temps cumulé d'un nombre important de requêtes successives, où la latence réseau a toute son importance.
Dans une requête 'normale', les lignes ne sont pas envoyées une par une, bien évidemment, ce qui permet tout de même de tolérer de la latence. Sauf si vous (ou votre driver) passez par un curseur et effectuez des fetchs des enregistrements un par un.
Marc.
Hors ligne
Bonjour,
Nous allons essayer, je vous tiens au courant.
Merci de m'avoir orienté.
Babourius
Hors ligne
Bonjour,
Nous avons mis certaines de nos fonctions dans un webservice qui se trouve sur la même machine que la base de données (serveur dédié hébergé)
Résultat impressionnant avec cette méthode : pour une même requête, le temp de réponse pour obtenir le résultat est considérablement diminué !!
Marc, merci encore de vos conseils !! Nous allons généraliser ça à toute l'application.
Babourius
Hors ligne
L'idéal serait évidemment d'avoir la base et l'application sur le même réseau?
Je présume que vous avez des contraintes qui vous en empêchent ?
Marc.
Hors ligne
Bonjour Marc,
Nous avons basculé toute l'application en webservices, et il n'y a pas photo... rapidité augmentée en flèche.
Effectivement, il nous est impossible d'avoir l'application et la base sur le même réseau : l'application est déployée sur de nombreux points de vente, et la base sert non seulement à l'ensemble de ces points de vente, mais aussi à des ventes sur internet.
Par contre, nous observons un phénomène curieux :
Plus nous sollicitons le webservice (depuis appli en VB.net, je le rappelle), plus le temps de réponse augmente.
Nous faisons 10 fois la même requête depuis l'appli,. La première fois, elle prend 100 ms... et ce temps augmente à chaque sollicitation : 113 ms, 132 ms, 164 ms...
Au redémarrage du soft, tout redevient normal, le temps est redescendu autour de 100 ms.
Et ça recommence...
Sauriez-vous d'où cela peut venir ?
Babourius
Hors ligne
De votre soft, je pense 
Plus sérieusement, aucune idée, probablement pas de la base elle même, sauf si vous exécutiez toutes les requêtes en parallèles, dans ce cas vous pourriez évidemment avoir une contention sur le disque ou le processeur.
Dernière hypothèse, si c'est niveau base, votre webservice met à jour beaucoup de données, et la base grossit au fur et à mesure ?
Marc.
Hors ligne
Non, pas de grossisement de la base, celà se produit même sur des reqetes de lecture...
Effectivement, le fait que le temps diminue au redémarrage du soft nous orient vers un souci sur notre soft... Nous allons investiguer...
Babourius
Hors ligne
