Discussion :

[Ghurdyl]

Bonjour

Je suis confronté à un problème qui dépasse largement mes connaissances ...

Je suis en train de développer un serveur web de génération de carte (dessin vectoriel)
J'utilise pour ce faire la librairie mapnik (C++ natif) que j'ai wrappé en C++/cli.

Ce même wrapper que j'inclus dans mon projet ASP.Net C#.

Lorsque j'effectue une requête unique d'image, tout se passe bien.
Mais dès que le serveur (IIS) doit traiter plusieurs requêtes simultanément j'ai des erreurs qui remontent de couches profondément encrées dans la dll de mapnik. ("access viloation" souvent)
Au bout de quelques requêtes des messages erreurs disant que l'espace est insuffisant pour traiter la demande ... pour finalement arriver à-ce que le serveur me dise que trop d'utilisateurs utilisent le service ...

Je cherche donc un peu à cerner le problème.

1. Comment se comporte les DLL inclues dans le serveur au niveau de l'espace mémoire ? 1 requête = 1 thread = 1 occurrence isolée et indépendante des autres ?
Ou bien je peux considéré que ma DLL est chargé une fois pour toutes et que donc les accès concurrent sont possibles ?

2. où puis-je trouver de l'info quant à la façon avec laquelle IIS gère plusieurs requêtes à la fois ?

3. Quelles sont les pistes, vers quoi dois-je m'orienter, pour contourner le problème ?

Dans un premier temps, je pensais à une variable au niveau du serveur me permettant de définir si une tuile est en cours de création et faire patienter les autres. (+/- 200 ms/tuile)
- mais puis-je être sûr que ma variable va persister ?
- Est-ce réellement fiable ?
- Cela va créer un goulet d'étranglement ...
- Comment faire "patienter" les autres requêtes ?

Merci de votre aide

[Immobilis]

Salut,

Je ne connais pas ce composant, mais pour palier les problèmes d'accès concomitants à une ressource, il y a le pattern singleton.

A+

[Kaidan]

Toute tentative de synchronisation manuelle sur une DLL qui semble ne pas supporter le multi-threading risque effectivement de créer un goulot d'étranglement, surtout que la génération d'une carte prend plus de 200ms (ce qui est très long ... 10 utilisateurs connectés et il faut attendre plus de deux minutes avec une forte probabilité que le navigateur parte en TimeOut avant...).

Je te propose un petit test :

Créer une application Console qui appelle, avec des paramètres classiques, la librairie mapnik (comme le ferait la page ASP.NET). Créer une autre application Console qui se charge de lancer 5 fois (par exemple) la première application en même temps. Est-ce que tout se passe bien dans ce cas ? où il y a encore des erreurs ?

Ce test devrait répondre à ta question 1 : dans ce test, on est sûr que la DLL est chargée plusieurs fois (une fois par application lancée). Si ça fonctionne, c'est que ASP.NET ne la charge qu'une fois, que les accès sont concurrents et que ça plante (à mon avis, c'est le cas).

A la question 2, il y a pas mal d'informations sur le cycle de vie des applications ASP.NET dans la MSDN (en fait, ce n'est pas IIS qui gère les demandes ASP.NET, il se charge uniquement de les transmettre à l'ISAPI ASP.NET).

A la question 3, tu as une réponse dans le test que j'ai proposé. Si ça fonctionne, tu peux exécuter depuis ton application ASP.NET la librairie dans un process séparé, attendre le résultat et le retourner au client.

[Ghurdyl]

Bonjour,

merci pour vos réponse, je vais creuser ces différentes pistes.

Pour ce qui est de lancer 5x l'application, j'ai fait ce genre de test entre temps et là, il n'y a pas de problème.

J'ai créer une synchronisation assez moche et brutale qui supprime les problèmes d'accès concurrent (et tues mes performances) histoire de tester un peu plus loin.
Là où j'ai toujours des truc louches, c'est qu'au bout d'une centaine de tuiles j'ai mon serveur qui se met en blocage "too many users connected", obligé de lui infliger un "iisreset"
Est-ce que des fuites mémoires au niveau du C++ pouraient en être la cause ?
J'ai des messages erreur "Espace insuffisant pour traiter cette commande" qui remonte dans mon application ...

Existe-t-il une interface pour pouvoir voir la mémoire allouée/consommée par IIS ?

[Kaidan]

Pour ce qui est de lancer 5x l'application, j'ai fait ce genre de test entre temps et là, il n'y a pas de problème.

Le plus simple est donc de créer un programme console qui sera en charge, en fonction de paramètres, d'utiliser la DLL C++ et de créer le fichier. En utilisant System.Diagnostics.Process, il est facile d'exécuter un process, de passer des paramètres (ProcessStartInfo) et d'attendre la fin de l'exécution avant de continuer (WaitForExit). De plus, ça résoud les problèmes de fuite de mémoire puisque le process est terminé et la mémoire libérée à la fin de l'exécution.

[Ghurdyl]

J'ai pas mal réfléchi à cette solution en effet ça me parait tout à fait viable et c'est bien plus simple à maintenir car pratiquement indépendante du serveur.

Mais comment puis-je récupérer le résultat de d'exécution de cette thread ?
Il s'agit d'un std::string contenant les bytes de l'image. Si je conserve le wrapper que j'ai, je peux éventuellement retourner un System.String mais comment le récupérer dans le processus appelant ? Un tutoriel là dessus ?

[Kaidan]

Il y a pas mal de façons de faire.

Tu peux par exemple utiliser les AnonymousPipe de System.IO.Pipes (3.5) ou .NET Remoting ou WCF ou même tout simplement écrire sur la Console.Out et rediriger le flux vers un Stream lors de la création du Process.

[Ghurdyl]

Ok merci.

Je pense que je vais m'orienter vers le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

string output = proc.StandardOutput.ReadToEnd();

http://faqcsharp.developpez.com/?pag...yst_procstdout

Je vais juste devoir trouver le moyen d'écrire mes bytes sans perdre de données puisse que ce n'est pas une std:string standard mais une collection de byte dont beaucoup sont interprété comme des caractères de fin de chaine.
Je l'avais déjà résolu, (ici) il va juste falloir que j'adapte.

[Ghurdyl]

Bonjour,

Je ré-ouvre le topic car la solution du stdout commence à provoquer ma calvitie ...

En effet après avoir beaucoup peiné avec les encodage, j'ai fini par trouver que pour lire mes images sur stdout je dois définir ce flux en mode binaire et en en plus, à l'appel du process, définir l'encodage à UTF-7.

Ce qui me donne une image interprétable mais altérée.
(plus de détails sur ce topic )

Donc au lieu de faire de l'acharnement thérapeutique et surtout à l'aveuglette je pense étudier une des uatres solutions que tu popose, Kaidan.
Ces procédés m'étant complètement inconnus, est-ce que quelqu'un peut m'indiquer des liens vers de la documentation (idéalement un tuto) pour utiliser ces techniques ?

je vous remercie

[Kaidan]

Tu pourrais sauvegarder l'image dans un fichier temporaire et utiliser la Console pour retourner uniquement le nom du fichier.

[Ghurdyl]

Merci, pour l'idée.

C'est actuellement la solution mise en place mais point de vue performance c'est pas génial, 1 seconde par tuile de 256 x 256. (~45 Ko)

J'aimerais donc trouver une solution qui me permettre d'éviter le disque dur.

[Kaidan]

Je suis pas sûr que le disque dur soit le facteur limitant. 45 ko c'est que dalle...

[Ghurdyl]

je pense en effet que je consomme beaucoup de temps à l'initialisation du processus et ferai un pool à mon avis pour pouvoir gagner de ce côté.

cependant si je peux également gagner côté disque dur, ce n'est pas perdu.

j'ai cherché vaguement un tuto expliquant comment utiliser les anonymous pipe mais je n'ai pas trouvé d'exemple simple et complet (producteur + consommateur)

[Ghurdyl]

solution par ici