[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [Tsp-devel] gérer un nombre de sym boles...hum...important
From: |
TSP |
Subject: |
RE : [Tsp-devel] gérer un nombre de sym boles...hum...important |
Date: |
Thu, 10 Mar 2005 16:38:43 +0100 |
Et il faudrait aussi une API pour recuperer le nombre de symboles coté
provider.
Maintenant pour gdisp en mode interactif, c'est sur que tu es obligé de
passer par le request info.
Tu as essaye un coups de profiler avec gprof pour voir quelle fonction
prenait du temps ? C'est sans doute l'appel RPC, mais a verifier. Si oui, la
structure est très grosse (en + du nom on a 6 entiers, et un opaque, c'est à
dire que l'on double au moins la taille de la structure en moyenne, + les
appels à xdr_decode).
On pourrait aussi ne recuperer que la liste des noms dans le request (+
infos du provider), et demander les infos pour la liste de symbole qui nous
interessent.
Y++
-----Original Message-----
From: Stephane Galles [mailto:address@hidden
Sent: Thursday, March 10, 2005 1:38 PM
To: address@hidden
Cc: address@hidden
Subject: Re: [Tsp-devel] gérer un nombre de symboles...hum...important
Hum...A la décharge de jSynoptic, je pense qu'il suffit juste
d'augmenter la taille de mémoire disponible dans Java au lancement
(c'est une sécurité pour éviter qu'un process ne gèle une machine)
Actuellement le lancement par 'ant jsynoptic-run' se fait avec la taille
par défaut. Mais dés qu'on fait des choses un peu osées, il faut la
modifier.
Pas le temps là, mais je fais cela ce soir (donc cette nuit...)
A vu de nez, quand tu a lancé tsp_gdips+ la taille mémoire de ton PC
a chuté de combien ?
Néamoins, effectivement le fichier de conf xml s'impose de plus en plus.
Steph
address@hidden wrote:
>Je joins à mon mail un petit screenshot
>d'un TSP gdisp+ qui a mis environ 1 minute à démarrer,
>je vous laisse chercher pourquoi...
>
>A noter qu'en voulant connecter jsynoptic à ce
>provider TSP OPERATIONNEL (bb_provider),
>il m'a gentiment explosé à la tronche--> "Out of Memory".
>
>Ce n'est pas le cas de tsp_gdisp+ qui a juste "souffert"
>pour démarrer.
>
>A noter que même si certain consumer ont souffert le
>provider lui semblait peinard :))
>Je resalue stéphane pour ça.
>
>Donc il faut ABSOLUMENT prévoir que:
>********************************************
>les consumers ne fasse PAS SYSTEMATIQUEMENT
>une requete "tsp_request_infos".
>********************************************
>
>je vois 2 solutions à ça,
>
>1) La première est en cours fichier de conf.
> (sauf que dans le cas de jsynoptic ça marche pas
> aujourd'hui parce qu'on ne sait pas créer un
> fichier de conf sans se connecter à un provider
> et donc envoyer l'infâme request_infos...)
>
>2) La deuxième c'est qu'on implemente une API
> requests_infos_limited qui renvoie un nombre limités
> de symboles qui correspondent à un pattern (regexp)
> on peut/doit imaginer un moyen de les découvrir
> tous mais par petit bout...
>
>Voila quand on laisse des utilisateurs mettre ...
>autant de symboles qui veulent ce que ça donne :))
>
>Eric
>
>
>
>
>
> ------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel
important_notice.txt
Description: Text document
- RE : [Tsp-devel] gérer un nombre de sym boles...hum...important,
TSP <=