Discussion :

[didier.cabale]

Bonjour,

j'ai développé un CGI installé sur MS IIS. Ce CGI est amené à lire /écrire sur divers fichiers xml.
Supposons qu'une 10aine de requêtes HTTP soient envoyées en même temps (par différents internautes) sur mon CGI. Comment risque-t-il de réagir? Tous les internautes seront-ils servis en même temps? Si non, quel pourait être le délai d'attente?
Autre manière de voir les choses: IIS +CGI sont-ils:
Mono-thread: -> existence d'une file d'attente système -> temps de réponse long pour les derniers servis, mais appli sécurisée?
Multi-thread: -> temps de réponse court, mais risque de conflit sur les écritures fichiers?
Merci pour votre aide
Didier

[Oluha]

je vais peut être me planter mais je pense que le principe est le même que si plusieurs personnes interroge en même temps une page ASP non ?

[didier.cabale]

je vais peut être me planter mais je pense que le principe est le même que si plusieurs personnes interroge en même temps une page ASP non ?

D'après moi, ce n'est pas sur, car l'exécution d'une page ASP fait partie du processus IIS. Je pense que çà serait la même chose que la page ASP si j'avais utilisé une ISAPI au lieu d'un CGI.
Mais admettons que j'exécute une page ASP, quid des requêtes en lecture /écriture concurrentes?
Merci
Didier

[matazz]

Je te confime que IIS est MultiThread (il gère chaque appel sur un thread), donc il faut l'intégrer dans le développement.

[didier.cabale]

.. quid des requêtes en lecture /écriture concurrentes?

1. merci pour ta réponse Matazz
2. permettez-moi de soumettre ma question à nouveau: si je ne me fais pas de soucis pour la lecture d'un fichier texte en processus multithread, qu'en est-il de l'écriture ?
Merci

[matazz]

Ben ce qui est clair,c'est que si tu modifie un fichier quand un autre est en train de le lire tu risque d'avoir des problème.

Moi je te conseille pour l'écriture d'ouvrir le fichier en mode exclusif, et chaque thread de lecture et d'écriture attend jusqu'a ce qu'il puisse l'ouvrir.

Par contre ça risque de ralentir ton CGI car il va y avoir des demandes qui vont attendre pour pouvoir lire ou écrire.

Ca dépend beaucoup des fréquences d'écritures.

Tous tes fichiers peuvent-êtres modifiés ?
ou seulement certains.

[didier.cabale]

Tous tes fichiers peuvent-êtres modifiés ?
ou seulement certains.

La plupart des fichiers sont en lecture seule -> no pb
J'ai 2 fichiers en lecture /écriture:
- le fichier des logs: on y lit lors de chaque requête http, càd très fréquemment, et on y écrit lors de chaque ouverture de session.
- le fichier des commandes: on y lit quand on veut consulter les commandes, et on y écrit à chaque fois qu'on enregistre une commande.
Donc si je comprend bien, tu me recommanderais de veiller à l'accès exclusif sur le fichier lors de l'écriture. Mais que se passerait-il si un utilisateur demande à lire un fichier qui est en cours d'écriture? Windows le mettra-t-il en file d'attente, puis permettra la lecture quand l'écriture sera réalisée? ou bien renverra-t-il un message d'erreur?

Merci pour votre aide
Didier

[matazz]

Oui ->

Donc si je comprend bien, tu me recommanderais de veiller à l'accès exclusif sur le fichier lors de l'écriture.

...Mais que se passerait-il si un utilisateur demande à lire un fichier qui est en cours d'écriture? Windows le mettra-t-il en file d'attente, puis permettra la lecture quand l'écriture sera réalisée? ou bien renverra-t-il un message d'erreur?

Windows te renverra un message d'erreur comme quoi tu n'as pas le droit d'acceder au fichier.
En fait c'est à toi de gérer dans to cgi l'endormissement du thread tant que le fichier n'est pas ouvrable.

Sinon, moi dans une DLL ISAPI, j'ouvrai un fichier log en mode "Append", mais dans certains cas, quand j'avais plusieurs instructions "Write", les lignes étaient intercallées.

Le mieux c'est de faire des tests.

Cela dit si tu as vraiement beaucoup de requêtes, il vaudrai peut-être mieux utiliser une base de données.

[didier.cabale]

Le mieux c'est de faire des tests

Je pense aussi

Cela dit si tu as vraiement beaucoup de requêtes, il vaudrai peut-être mieux utiliser une base de données

Eh oui, on en finit toujours là, car elle, elle est faite pour çà!
Merci pour ton aide, Matazz

[matazz]

de rien