Réf. : Probleme Traffic réseau PostgreSQL

Antony,

Comme il n'y avait pas beaucoup de réponse à ton post, j'ai pris mon
courage à 2 mains et ai fait quelques analyses. Pour ne pas avoir à me
perdre dans les sources de PostgreSQL, j'ai installé WireShark sur mon
micro et j'ai regardé les messages échangés entre pgAdmin sur mon micro et
un PostgreSQL sur un serveur Linux.
WireShark est vraiment génial, puisqu'il sait formater en clair les
messages du protocole PostgreSQL :-)
J'en ai déduit ceci sur la taille des messages échangés (hors couches
réseau au dessous) :

1) A l'aller, on a le texte de la requête avec simplement un overhead de 6
octets.

2) Au retour, on a un message (découpé éventuellement en plusieurs paquets
selon la taille) composé de :
- la description des lignes de la table résultat, dont la longueur en
octets est égale à :
7 + ( 19 * nombre de colonnes) + somme des longueurs des noms des
colonnes,
- les lignes de données (voir plus bas),
- 2 commandes "command completion" et "ready for query" représentant 18
octets.
Chaque ligne se compose de :
- une partie fixe de 7 octets,
- la liste des colonnes.
Chaque colonne se compose de :
- une partie fixe de 4 octets,
- la valeur de la colonne.

Tout est donc très logique.

3) Contenu des colonnes :
Pour les colonnes de type CHAR, on trouve le contenu de la colonne (je n'ai
pas fait attention aux questions d'encodage qui peuvent j'imagine avoir un
impact sur la taille physique de chaque caractère). il n'y a pas de
compression, même pour les blancs à droite.
Pour les colonnes de type VARCHAR, on trouve évidemment la longueur réelle
du contenu de la colonne et non sa longueur maximale.
Pour les colonnes BYTEA, les octets "non imprimables" sont représentés par
leur séquence d'escape (\nnn).
Pour les colonnes numériques, la donnée est représentée sous forme de texte
de longueur variable, c'est à dire la suite des chiffres nécessaires à la
représentation du nombre.

4) Les requêtes retournant une ligne et celles retournant plusieurs lignes
semblent avoir la même structure, quelle que soit le nombre de colonnes.

Voici donc ma compréhension de la structure des messages. Elle est
peut-être approximative mais ça peut aider. Quelqu'un a peut-être des
précisions ?

J'imagine que le dialogue entre pgAdmin et PostgreSQL que j'ai observé est
le même que celui des autres clients et drivers disponibles. Quelqu'un
peut-il me confirmer ?

Pour comprendre pourquoi Oracle qui est un peu moins bon sur 1 ligne
devient meilleur sur plusieurs lignes, il faudrait faire ce même exercice
avec Oracle.
A moins que quelqu'un ait une déjà une idée sur la question...

Bon week-end. Philippe.

Stéphane Schildknecht
<stephane(dot)schildknecht(at)postgr Pour : "'pgsql-fr-generale(at)postgresql(dot)org'" <pgsql-fr-generale(at)postgresql(dot)org>
esqlfr.org> cc : antony(dot)resbeut(at)bull(dot)net
Envoyé par : Objet : [pgsql-fr-generale] Probleme Traffic réseau PostgreSQL
pgsql-fr-generale-owner(at)postg
resql.org


11/07/2008 00:51

Bonjour,

Je fais suivre un message d'un souscripteur dont les messages n'arrivent
pas jusqu'à la liste... En attendant de comprendre pourquoi ils
n'arrivent pas sur la liste...

Stéphane Schildknecht

###############

Bonjour,

Je fais des tests réseau de comparaison entre Oracle et PostgreSQL et
j'ai des gros écarts...

Lorsque je fais un "select toto from table where titi='x'" alors
le nombre d'octet de la réponse est identique entre Oracle et PostgreSQL
(parfois meilleur sous PostgreSQL).

Si j'enlève la condition "where" alors PostgreSQL est beaucoup plus
bavard qu'Oracle aussi bien en nombre de packet que sur la taille des
packets. Et c'est pire si l'on fais un vidage "select * from table" brutal.
Est-ce normal ?

Pour exemple :
SELECT id_commande FROM COMMANDE (VARCHAR(28))
SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'00" |1 896 702 |1105 bytes |67.286 |1716
Oracle |0'00" |1 496 151 |846 bytes |26.168 |1768
Informix |0'00" |1 858 862 |999 bytes |22.724 |1859

SELECT date_sign FROM COMMANDE (DATE)
SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'00" |868 573 |1117 bytes |18.999 |777
Oracle |0'00" |453 126 |876 bytes |8.245 |517
Informix |0'00" |587 446 |1018 bytes |4.882 |577

SELECT id_commande FROM COMMANDE where ID_COMMANDE =
'200706202054510076503-276501' (VARCHAR(28))
SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'00" |567 |81 bytes |0.024 |7
Oracle |0'00" |975 |139 bytes |0.043 |7
Informix |0'00" |904 |82 bytes |0.046 |11

SELECT * FROM COMMANDE (46255 lignes)

SGBD |Temps |Octets |Packets size |Avg Mbit/sec |Packets
PostgreSQL|0'13" |16 801 515 |1 008 bytes |9.900 |16 653
Oracle |0'08" |06 889 074 |694 bytes |6.752 |09 920
Informix |0'13" |11 481 870 |967 bytes |7.054 |11 867

Merci de votre réponse ou avis.

Antony Resbeut

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale