Discussion :

[frantzgac]

Bonjour

J'exploite une BD Firebird 2.5 installée sur un serveur Debian chez OVH.
Je me connecte avec une application C++ Builder 6 qui fonctionne indifféremment en local ou en réseau.
(Si le paramétrage de Firebird et OpenVPN intéresse quelqu'un je peux les communiquer)

Un de mes clients (un peu atypique) rencontre des temps de réponses décourageant : 30 secondes pour un volume de données descendant d'environ 500Ko (chiffre obtenu par différence des compteurs TX de la commande linux ifconfig -a du serveur).
Je précise que ma connexion internet affiche 50Mbit/s descendant (testdebit.fr)

Je lui ai proposé de faire des tests d'amélioration.

Première idée : changer de serveur OVH pour un modèle d'un débit plus important
Deuxième idée : passer à Firebird 3
Troisième idée : paramétrer plus finement


Quels paramètres ?
Ceux mentionnés par Carlos H.Cantu dans "Migration guide to FB 3." donc WireCompression (firebird.conf du client) et TcpRemoteBufferSize (firebird.conf du serveur)

Utiliser UDP moins dispendieux en emballage réseau si j'ai bien compris.

Selon ce site
https://serverfault.com/questions/68...pu-utilization

j'ai testé aussi :

sndbuf 0
rcvbuf 0

et bien sûr

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

J'ai essayé de combiner et varier tous ces paramètres sans obtenir d'amélioration significative.

Si quelqu'un a une autre idée je suis prêt à la tester.

J'envisage maintenant de tester un base sur Firebird 4 avec le système de réplication... Comme les plus gros volumes sont descendants et non montant, cette solution parait en théorie, idéale. Si quelqu'un a un avis à ce sujet...

[binarygirl]

Un de mes clients (un peu atypique) rencontre des temps de réponses décourageant : 30 secondes pour un volume de données descendant d'environ 500Ko (chiffre obtenu par différence des compteurs TX de la commande linux ifconfig -a du serveur).

Mais savez-vous combien de temps prend la requête pour s'exécuter sur le serveur ? C'est peut-être la requête qui est lourde à exécuter, mais ne renvoie pas beaucoup de données.
Il est peu probable que ce soit un problème de bande passante.
Personnellement, si vous avez exclu la première hypothèse (requête lourde à exécuter), je pencherais pour un éventuel problème réseau côté client: routage ou DNS. Ou mauvaise configuration du VPN.
Si c'est possible j'essaierais de sniffer du trafic sur le client avec Wireshark ou tcpdump par exemple, pour voir ce qui se passe. Et en même temps côté serveur, en filtrant sur l'adresse IP du client pour isoler le trafic.

[frantzgac]

Bonjour
Merci de votre réponse.
J'ai en effet observé le trafic réseau par Wireshark sur le client.
Le serveur répond quasi instantanément à la requête (c'est observable par WireShark)
Les 528412 octets (mesurés sur tun0) envoyés par le serveur (réponse à plusieurs requêtes non sécables) s’échelonnent du Time 0 à 29.98 soit 30 secondes.
Il y 1425 trames à raison d'une trame toutes les 20 ms en moyenne.
Je fournis la feuille excel des échanges de trames pour avoir votre avis car personnellement je ne sais pas y repérer identifier des dysfonctionnements.http://www.makhno.fr/temp/testrequet..._8k_nocomp.ods
Il semble que le téléchargement entraine une alerte de sécurité... alors je le renvoie ici par wetransfer https://we.tl/t-3KmS9Sg2Wb
Il y a deux graphiques à la fin des données : intervalles entre les trames / chronologie des trames

[frantzgac]

J'ai tenté une requête un peu plus bestiale : un sql * sur la plus grosse table (5 Mo 50.000 lignes)
Le temps de transfert est le même : 30 secondes.
Avec la même base, sur mon PC la requête répond instantanément.

[frantzgac]

J'ai ajouté un graphique intéressant à l'analyse par tableur

https://we.tl/t-MwLDxGhahg

Je suis intrigué par la rapidité des échanges entre les trames 24 et 100 environ comparativement t les échanges suivants. Voir graphique "cumul RX/temps" en fin de feuille.

Je précise que je suis connecté à internet par un routeur 4G + SIM (et mon client aussi car sa box donnant des débits minables je l'ai convaincu d'utiliser un routeur 4G en attendant la fibre)

[frantzgac]

Configuration OpenVPN côté Serveur

# Serveur TCP/443
mode server
proto tcp
port 443
dev tun
# Cles et certificats
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
tls-auth ta.key 1
key-direction 0
cipher AES-256-CBC
# Reseau
server 10.8.0.0 255.255.255.0
push "comp-lzo no"
keepalive 10 120
# Securite
user nobody
group nogroup
persist-key
persist-tun
comp-lzo no
# Log
verb 3
mute 20
status openvpn-status.log
log-append /var/log/openvpn.log
topology subnet
# permettre à plusieurs clients d'utiliser la même clé
duplicate-cn

Configuration OpenVPN côté client

# Client
client
dev tun
proto tcp
remote X.X.X.X
resolv-retry infinite
cipher AES-256-CBC
; client-config-dir ccd
# Cles
ca "c:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "c:\\Program Files\\OpenVPN\\config\\pc.crt"
key "c:\\Program Files\\OpenVPN\\config\\pc.key"
tls-auth "c:\\Program Files\\OpenVPN\\config\\ta.key" 1
key-direction 1
# Securite
nobind
persist-key
persist-tun
comp-lzo
verb 3

[frantzgac]

Problème résolu.
Il venait d'une salve de requêtes non repérées dans le code.
OpenVPN, Fireguard et les serveurs VPS d'OVH ne sont pas en cause.
Merci à ceux qui se sont intéressés à la question.