Discussion :

[R&B]

Bonjour

Je recherche de piste sur une éventuelle limite dans le débit d'écriture (ajouts et modifications) dans les fichiers HyperFile et la disponibilité des index, le tout sur une base C/S.

Contexte : une base HF en client serveur partagé par une dizaine de postes ainsi qu'un exécutable sur le serveur pour synchroniser des données.

Symptôme : des recherches bloquantes n'aboutissent pas. Non pas que l'enregistrement n'existe pas ou qu'il est bloqué... mais semble-t il parce que l'index n'as pas eu le temps de se mettre à jour. On a mis en log les erreurs de retour de nos fonctions Hxxx sans résultat (logs vides malgré l'erreur) et la lecture bloquante ne s'opère pas. Du coup, la procédure déclenche une création d'enregistrement et donc un doublon se génère. C'est ce qu'on doit éviter (ne pas me parler de clé unique, c'est pas le sujet de ce message).

Coté exploitation les postes passent tous pas la même procédure pour l'écriture dans ce fichier et c'est celle qui qui a fait l'objet de nos tests sur le blocage, la position etc...
En revanche, nous avons aussi l'exécutable sur le serveur qui écrit vraiment mais vraiment beaucoup sur ce fichier. Dans ce cas, il récupère des informations dans un thread et met à jour ce fichier (oui, on gère bien le contexte HF...). On a facilement une écriture par seconde dans ce fonctionnement et ce en dehors des accès des 10 autres postes.

Une première utilisation des index fulltext nous avait montré qu'en HF classique, une trop grande fréquence de mise à jour nous cassait régulièrement l'index FTX. Le passage en C/S a résolu ce problème.

Dans le cas présent, nous avons une fréquence d'écriture encore plus élevée.
C'est ce qui me dirige vers la question : y a-t il un débit d'écriture au delà duquel les index ne suivent pas ? Je suis bien conscient de la bizarrerie de la question mais je ne vois pas d'autre raison à l'erreur que l'on rencontre.

[Bowen]

As-tu pensé à forcer l'écriture sur disque, pour être sûr que ce ne soit pas juste un problème de cache ?
Voir du côté de HForceEcriture(). Moi je ferais un test en surchargeant HAjoute() et HModifie(), pour qu'ils intègrent directement le HForceEcriture().
Ensuite, voir si tu as toujours l'erreur de lecture.
Par contre, c'est sensé te ralentir tes écritures...

[EDM-TAHITI]

Hello,
BOWEN a raison... a ceci, j'y ajouterais que le cache d'écriture est directement lié à la puissance de la machine qui héberge le serveur HFCS. J'utilise le mot 'Machine' car dans certains cas, ce n'est pas un serveur... un vrai...
Et quand je parle de puissance, ce n'est pas seulement la mémoire disponible (ca joue, certes), mais aussi la vitesse d'écriture du/des disques, le mode de gestion des disques (SATA, ATA), le niveau de sécurité (RAID 0, 1, 5), si ce mode est en natif sur la carte mère ou si c'est une carte qui gère cela, etc...
Enfin, mais ce que je vais écrire est assez rare, la fiabilité du réseau, s'il est en full/half duplex, la gestion des collisions réseaux (HUB ou Switch?), etc...
Ensuite viens le paramétrage du serveur HFCS (sauvegarde de nuit non finie? - cela m'est arrivé une fois, ca a mis le brin...)...
Je sais pertinement que je ne répond pas directement, mais ce sont les pistes que j'explorerais si j'avais à rencontrer ce genre de soucis...
mais le sujet est très intéressant... j'espère que tu trouveras rapidement la/les solutions à tes soucis.

[R&B]

Salut et merci à vous deux.

Nous avons bien programmé un mode de sécurité (hSecurité) qui permettrait de jouer sur le point cité par Bowen. Je vais donc voir comment l'activer et ce que cela implique en exploitation sur site.

Ensuite je vais étudier tes observations, Eric, car oui, il ne s'agit pas forcément d'un serveur et tout ce que tu mets en lumière est présent.

C'est effectivement intéressant mais le coté non systématique de l'erreur rends la chose très inconfortable et la données en question est simplement essentielle.
Je souleverai ce point à nouveau si j'ai d'autres éléments, mais il va falloir du temps. Nous sommes dans un cas à réactivité moyenne.