Bonsoir j'aurais besoin d'avoir un peu d'aide concernant un projet de
fin d'ann=E9e qui consiste =E0 r=E9cup=E9rer en temps r=E9el des informatio=
ns
boursi=E8res.
J'ai donc cod=E9 un client HTTP qui r=E9cup=E8re les informations sur un
site boursier le probl=E8me =E9tant que je souhaite r=E9cup=E9rer ces m=EAm=
e
informations pour plusieurs titres boursiers et cela au m=EAme moment
avec un temps de latence le plus r=E9duit que possible entre chaque
requ=EAte afin d'=EAtre sur de capturer toutes les informations =E0 peu pr=
=E8s
toute les secondes et donc en temps r=E9el.
Je me suis donc tourn=E9 vers les threads pour r=E9aliser cela mais je ne
sais pas si les performances sont bonnes aussi auriez-vous des
solutions =E0 me proposer concernant mon probl=E8me ?
Ce que je veux dire par l=E0 c'est, est-ce qu'il existe des techniques
efficaces pour affronter ce genre de probl=E8me de r=E9cup=E9ration en temp=
s
r=E9el sur plusieurs pages web ?
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des aspects marketing ou propagandistes).
Car : - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes. - passer par des sites boursiers, ça implique d'accepter les latences (internes) de ces sites. Et, ces latences peuvent être importantes (près de 20 minutes, pour certains sites connus).
Concernant les performances des threads en Python, elles sont largement suffisantes. Par contre, le point sensible, ce sera la (les ?) connexions Internet. Ainsi que la réactivité des sites/serveurs utilisés. Mais, là, ça ne dépend plus de toi...
@-salutations -- Michel Claveau
Bonjour !
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en
dehors des aspects marketing ou propagandistes).
Car :
- dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt
en centièmes de secondes, voire en millièmes.
- passer par des sites boursiers, ça implique d'accepter les latences
(internes) de ces sites. Et, ces latences peuvent être importantes (près
de 20 minutes, pour certains sites connus).
Concernant les performances des threads en Python, elles sont largement
suffisantes. Par contre, le point sensible, ce sera la (les ?)
connexions Internet. Ainsi que la réactivité des sites/serveurs
utilisés. Mais, là, ça ne dépend plus de toi...
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des aspects marketing ou propagandistes).
Car : - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes. - passer par des sites boursiers, ça implique d'accepter les latences (internes) de ces sites. Et, ces latences peuvent être importantes (près de 20 minutes, pour certains sites connus).
Concernant les performances des threads en Python, elles sont largement suffisantes. Par contre, le point sensible, ce sera la (les ?) connexions Internet. Ainsi que la réactivité des sites/serveurs utilisés. Mais, là, ça ne dépend plus de toi...
@-salutations -- Michel Claveau
NicolasP
> - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes.
Millièmes de secondes ? Petit joueur ! :p
Nicolas
> - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en
centièmes de secondes, voire en millièmes.
> - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes.
Millièmes de secondes ? Petit joueur ! :p
Nicolas
Michel Claveau - NoSpam SVP ; merci
Salut !
Ta remarque est intéressante.
Elle soulève la question de la récupération fiable des données temporelles, pour des valeurs plus précises que les millièmes de secondes.
Dans les PC actuels, je pense que cela n'est possible qu'avec du matériel (hard) additionnel. Les ordinateurs habituels ne gérant que le millième de seconde. Attn: je ne parle pas des processeurs et des chipsets, mais des ordinateurs vus à travers leur OS.
@+
MCI
PS : ceci dit, perso, je n'ai jamais eu besoin de travailler en dessous de la ms...
Salut !
Ta remarque est intéressante.
Elle soulève la question de la récupération fiable des données
temporelles, pour des valeurs plus précises que les millièmes de
secondes.
Dans les PC actuels, je pense que cela n'est possible qu'avec du
matériel (hard) additionnel. Les ordinateurs habituels ne gérant que le
millième de seconde. Attn: je ne parle pas des processeurs et des
chipsets, mais des ordinateurs vus à travers leur OS.
@+
MCI
PS : ceci dit, perso, je n'ai jamais eu besoin de travailler en dessous
de la ms...
Elle soulève la question de la récupération fiable des données temporelles, pour des valeurs plus précises que les millièmes de secondes.
Dans les PC actuels, je pense que cela n'est possible qu'avec du matériel (hard) additionnel. Les ordinateurs habituels ne gérant que le millième de seconde. Attn: je ne parle pas des processeurs et des chipsets, mais des ordinateurs vus à travers leur OS.
@+
MCI
PS : ceci dit, perso, je n'ai jamais eu besoin de travailler en dessous de la ms...
NicolasP
Michel Claveau - NoSpam SVP ; merci a écrit :
Salut !
Ta remarque est intéressante.
Elle soulève la question de la récupération fiable des données temporelles, pour des valeurs plus précises que les millièmes de secondes.
Dans les PC actuels, je pense que cela n'est possible qu'avec du matériel (hard) additionnel. Les ordinateurs habituels ne gérant que le millième de seconde. Attn: je ne parle pas des processeurs et des chipsets, mais des ordinateurs vus à travers leur OS.
@+
MCI
PS : ceci dit, perso, je n'ai jamais eu besoin de travailler en dessous de la ms...
Il ne s'agissait que d'une boutade.
Ceci dit, dans mon boulot, le temps réel peut se situer dans la gamme des milisecondes mais est plus souvent dans les microsecondes. Voire moins encore. Cela ne se passe pas sur PC mais sur du matériel spécifique. J'utilise un mélange de soft et de hard pour arriver à mes fins. Sur une de mes dernières cartes, le soft supporte 3 sources d'interruptions qui peuvent monter à 30KHz chacune. Donc 3 interruptions toutes les 33µs. Plus une autre source d'IT à plus faible fréquence plus du calcul et de la communication série. Evidemment, c'est programmé en C, pas en Python.
Nicolas
Michel Claveau - NoSpam SVP ; merci a écrit :
Salut !
Ta remarque est intéressante.
Elle soulève la question de la récupération fiable des données
temporelles, pour des valeurs plus précises que les millièmes de secondes.
Dans les PC actuels, je pense que cela n'est possible qu'avec du
matériel (hard) additionnel. Les ordinateurs habituels ne gérant que le
millième de seconde. Attn: je ne parle pas des processeurs et des
chipsets, mais des ordinateurs vus à travers leur OS.
@+
MCI
PS : ceci dit, perso, je n'ai jamais eu besoin de travailler en dessous
de la ms...
Il ne s'agissait que d'une boutade.
Ceci dit, dans mon boulot, le temps réel peut se situer dans la gamme des milisecondes mais est plus souvent dans les microsecondes. Voire moins encore. Cela ne se passe pas sur PC mais sur du matériel spécifique. J'utilise un mélange de soft et de hard pour arriver à mes fins. Sur une de mes dernières cartes, le soft supporte 3 sources d'interruptions qui peuvent monter à 30KHz chacune. Donc 3 interruptions toutes les 33µs. Plus une autre source d'IT à plus faible fréquence plus du calcul et de la communication série. Evidemment, c'est programmé en C, pas en Python.
Elle soulève la question de la récupération fiable des données temporelles, pour des valeurs plus précises que les millièmes de secondes.
Dans les PC actuels, je pense que cela n'est possible qu'avec du matériel (hard) additionnel. Les ordinateurs habituels ne gérant que le millième de seconde. Attn: je ne parle pas des processeurs et des chipsets, mais des ordinateurs vus à travers leur OS.
@+
MCI
PS : ceci dit, perso, je n'ai jamais eu besoin de travailler en dessous de la ms...
Il ne s'agissait que d'une boutade.
Ceci dit, dans mon boulot, le temps réel peut se situer dans la gamme des milisecondes mais est plus souvent dans les microsecondes. Voire moins encore. Cela ne se passe pas sur PC mais sur du matériel spécifique. J'utilise un mélange de soft et de hard pour arriver à mes fins. Sur une de mes dernières cartes, le soft supporte 3 sources d'interruptions qui peuvent monter à 30KHz chacune. Donc 3 interruptions toutes les 33µs. Plus une autre source d'IT à plus faible fréquence plus du calcul et de la communication série. Evidemment, c'est programmé en C, pas en Python.
Nicolas
Pierre Maurette
Shakan, le 14/05/2009 a écrit :
Bonsoir j'aurais besoin d'avoir un peu d'aide concernant un projet de fin d'année qui consiste à récupérer en temps réel des informations boursières.
J'ai donc codé un client HTTP qui récupère les informations sur un site boursier le problème étant que je souhaite récupérer ces même informations pour plusieurs titres boursiers et cela au même moment avec un temps de latence le plus réduit que possible entre chaque requête afin d'être sur de capturer toutes les informations à peu près toute les secondes et donc en temps réel.
Je me suis donc tourné vers les threads pour réaliser cela mais je ne sais pas si les performances sont bonnes aussi auriez-vous des solutions à me proposer concernant mon problème ?
Ce que je veux dire par là c'est, est-ce qu'il existe des techniques efficaces pour affronter ce genre de problème de récupération en temps réel sur plusieurs pages web ?
Je me demande si vous ne faites pas une erreur dans l'analyse du problème. A moins que l'analyse ne vous soit imposée ? Ne rigolez pas, j'ai vu le cas, avec mon fils qui avait un projet de fin d'études qui aurait pu être passionnant si des prérequis ne l'avaient transformé en exercice de style. Je ne pige pas tout, mais je vous suggére une expérience simple, bien que contraignante si vous n'aimez pas l'odeur de la sueur et du vestiaire. Vous choisissez un soir où il se passe quelque chose dans le football, ou le rugby, ou les courses de voitures. Mais le football, c'est bien. Par exemple hier soir, à partir de 21h, Bordeaux jouant à Valenciennes. Vous vous connectez à deux ou trois sites de premier plan qui proposent un suivi "en direct" du match. Vous mettez en place une stratégie pour raffraichir en permanence. En parallèle, vous branchez un poste de radio - hertzienne - , ou de télévision. Je ne pense pas qu'il soit utile que je développe... Juste un détail: vous rendez_vous compte qu'un bond satellite (géostationnaire), c'est en aller simple 1/4 de seconde, incompressible grâce à Albert. Pour les bourses asiatiques, ça peut faire 6 bonds, en aller-retour 3 secondes - négligeables - à ajouter au temps de saisie...
-- Pierre Maurette
Shakan, le 14/05/2009 a écrit :
Bonsoir j'aurais besoin d'avoir un peu d'aide concernant un projet de
fin d'année qui consiste à récupérer en temps réel des informations
boursières.
J'ai donc codé un client HTTP qui récupère les informations sur un
site boursier le problème étant que je souhaite récupérer ces même
informations pour plusieurs titres boursiers et cela au même moment
avec un temps de latence le plus réduit que possible entre chaque
requête afin d'être sur de capturer toutes les informations à peu près
toute les secondes et donc en temps réel.
Je me suis donc tourné vers les threads pour réaliser cela mais je ne
sais pas si les performances sont bonnes aussi auriez-vous des
solutions à me proposer concernant mon problème ?
Ce que je veux dire par là c'est, est-ce qu'il existe des techniques
efficaces pour affronter ce genre de problème de récupération en temps
réel sur plusieurs pages web ?
Je me demande si vous ne faites pas une erreur dans l'analyse du
problème. A moins que l'analyse ne vous soit imposée ? Ne rigolez pas,
j'ai vu le cas, avec mon fils qui avait un projet de fin d'études qui
aurait pu être passionnant si des prérequis ne l'avaient transformé en
exercice de style.
Je ne pige pas tout, mais je vous suggére une expérience simple, bien
que contraignante si vous n'aimez pas l'odeur de la sueur et du
vestiaire. Vous choisissez un soir où il se passe quelque chose dans le
football, ou le rugby, ou les courses de voitures. Mais le football,
c'est bien. Par exemple hier soir, à partir de 21h, Bordeaux jouant à
Valenciennes. Vous vous connectez à deux ou trois sites de premier plan
qui proposent un suivi "en direct" du match. Vous mettez en place une
stratégie pour raffraichir en permanence. En parallèle, vous branchez
un poste de radio - hertzienne - , ou de télévision. Je ne pense pas
qu'il soit utile que je développe...
Juste un détail: vous rendez_vous compte qu'un bond satellite
(géostationnaire), c'est en aller simple 1/4 de seconde, incompressible
grâce à Albert. Pour les bourses asiatiques, ça peut faire 6 bonds, en
aller-retour 3 secondes - négligeables - à ajouter au temps de
saisie...
Bonsoir j'aurais besoin d'avoir un peu d'aide concernant un projet de fin d'année qui consiste à récupérer en temps réel des informations boursières.
J'ai donc codé un client HTTP qui récupère les informations sur un site boursier le problème étant que je souhaite récupérer ces même informations pour plusieurs titres boursiers et cela au même moment avec un temps de latence le plus réduit que possible entre chaque requête afin d'être sur de capturer toutes les informations à peu près toute les secondes et donc en temps réel.
Je me suis donc tourné vers les threads pour réaliser cela mais je ne sais pas si les performances sont bonnes aussi auriez-vous des solutions à me proposer concernant mon problème ?
Ce que je veux dire par là c'est, est-ce qu'il existe des techniques efficaces pour affronter ce genre de problème de récupération en temps réel sur plusieurs pages web ?
Je me demande si vous ne faites pas une erreur dans l'analyse du problème. A moins que l'analyse ne vous soit imposée ? Ne rigolez pas, j'ai vu le cas, avec mon fils qui avait un projet de fin d'études qui aurait pu être passionnant si des prérequis ne l'avaient transformé en exercice de style. Je ne pige pas tout, mais je vous suggére une expérience simple, bien que contraignante si vous n'aimez pas l'odeur de la sueur et du vestiaire. Vous choisissez un soir où il se passe quelque chose dans le football, ou le rugby, ou les courses de voitures. Mais le football, c'est bien. Par exemple hier soir, à partir de 21h, Bordeaux jouant à Valenciennes. Vous vous connectez à deux ou trois sites de premier plan qui proposent un suivi "en direct" du match. Vous mettez en place une stratégie pour raffraichir en permanence. En parallèle, vous branchez un poste de radio - hertzienne - , ou de télévision. Je ne pense pas qu'il soit utile que je développe... Juste un détail: vous rendez_vous compte qu'un bond satellite (géostationnaire), c'est en aller simple 1/4 de seconde, incompressible grâce à Albert. Pour les bourses asiatiques, ça peut faire 6 bonds, en aller-retour 3 secondes - négligeables - à ajouter au temps de saisie...
-- Pierre Maurette
Pierre Maurette
Méta-MCI (MVP), le 14/05/2009 a écrit :
Bonjour !
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des aspects marketing ou propagandistes).
Car : - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes.
Le temps réel se coinçoit-il par rapport au temps de réaction ? En régulation thermique industrielle, ou juste pour garder hors-gel une pelouse de football (j'y reviens ;-) ), c'est du vrai temps réel, mais les constantes de temps sont de l'ordre de l'heure, il me semble. Peut-être un peu moins parce qu'il faut disposer prioritairement de la dérivée des mesures, mais pas beaucoup moins...
- passer par des sites boursiers, ça implique d'accepter les latences (internes) de ces sites. Et, ces latences peuvent être importantes (près de 20 minutes, pour certains sites connus).
Ne peut-il pas y avoir dans le cas de sites gratuits et d'une telle latence le désir de profiter de l'information ?
-- Pierre Maurette
Méta-MCI (MVP), le 14/05/2009 a écrit :
Bonjour !
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des
aspects marketing ou propagandistes).
Car :
- dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en
centièmes de secondes, voire en millièmes.
Le temps réel se coinçoit-il par rapport au temps de réaction ? En
régulation thermique industrielle, ou juste pour garder hors-gel une
pelouse de football (j'y reviens ;-) ), c'est du vrai temps réel, mais
les constantes de temps sont de l'ordre de l'heure, il me semble.
Peut-être un peu moins parce qu'il faut disposer prioritairement de la
dérivée des mesures, mais pas beaucoup moins...
- passer par des sites boursiers, ça implique d'accepter les latences
(internes) de ces sites. Et, ces latences peuvent être importantes (près de
20 minutes, pour certains sites connus).
Ne peut-il pas y avoir dans le cas de sites gratuits et d'une telle
latence le désir de profiter de l'information ?
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des aspects marketing ou propagandistes).
Car : - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes.
Le temps réel se coinçoit-il par rapport au temps de réaction ? En régulation thermique industrielle, ou juste pour garder hors-gel une pelouse de football (j'y reviens ;-) ), c'est du vrai temps réel, mais les constantes de temps sont de l'ordre de l'heure, il me semble. Peut-être un peu moins parce qu'il faut disposer prioritairement de la dérivée des mesures, mais pas beaucoup moins...
- passer par des sites boursiers, ça implique d'accepter les latences (internes) de ces sites. Et, ces latences peuvent être importantes (près de 20 minutes, pour certains sites connus).
Ne peut-il pas y avoir dans le cas de sites gratuits et d'une telle latence le désir de profiter de l'information ?
-- Pierre Maurette
Shakan
Bonjour, j'ai lu tout vos messages avec attention et à vous lire il semblerait que le challenge relève de l'impossible en tout cas pour ce qui est d'obtenir en temps réel. Mais je tiens à rectifier en vous disant qu'une latence maximum de 2 secondes devra être la limite à ne pas dépasser.
Concernant les performances des threads en Python, elles sont largement
suffisantes.
Au niveau du code qui va me permettre d'envoyer plusieurs requêtes HTTP en parallèle est-ce que tu pense que ce dernier est d'une structure simple tel qu'on le présente dans la plupart des cours d'introduction aux threads ou bien il faudra que j'utilise des fonctions en plus, rendant mon code plus compliqué à lire mais néanmoins me permettant d'obtenir une latence de moins de 2 secondes entre chaque requête envoyée ?
J'aimerais avoir des suggestions à ce sujet si ce n'est trop vous demander. :)
Merci d'avance.
Bonjour, j'ai lu tout vos messages avec attention et à vous lire il
semblerait que le challenge relève de l'impossible en tout cas pour ce
qui est d'obtenir en
temps réel.
Mais je tiens à rectifier en vous disant qu'une latence maximum de 2
secondes devra être la limite à ne pas dépasser.
Concernant les performances des threads en Python, elles sont largement
suffisantes.
Au niveau du code qui va me permettre d'envoyer plusieurs requêtes
HTTP en parallèle est-ce que tu pense que ce dernier est d'une
structure simple tel qu'on
le présente dans la plupart des cours d'introduction aux threads ou
bien il faudra que j'utilise des fonctions en plus, rendant mon code
plus compliqué
à lire mais néanmoins me permettant d'obtenir une latence de moins de
2 secondes entre chaque requête envoyée ?
J'aimerais avoir des suggestions à ce sujet si ce n'est trop vous
demander. :)
Bonjour, j'ai lu tout vos messages avec attention et à vous lire il semblerait que le challenge relève de l'impossible en tout cas pour ce qui est d'obtenir en temps réel. Mais je tiens à rectifier en vous disant qu'une latence maximum de 2 secondes devra être la limite à ne pas dépasser.
Concernant les performances des threads en Python, elles sont largement
suffisantes.
Au niveau du code qui va me permettre d'envoyer plusieurs requêtes HTTP en parallèle est-ce que tu pense que ce dernier est d'une structure simple tel qu'on le présente dans la plupart des cours d'introduction aux threads ou bien il faudra que j'utilise des fonctions en plus, rendant mon code plus compliqué à lire mais néanmoins me permettant d'obtenir une latence de moins de 2 secondes entre chaque requête envoyée ?
J'aimerais avoir des suggestions à ce sujet si ce n'est trop vous demander. :)
Merci d'avance.
Xavier Maillard
At Wed, 13 May 2009 20:44:05 -0700 (PDT), Shakan wrote:
J'ai donc codé un client HTTP qui récupère les informations sur un site boursier le problème étant que je souhaite récupérer ces même informations pour plusieurs titres boursiers et cela au même moment avec un temps de latence le plus réduit que possible entre chaque requête afin d'être sur de capturer toutes les informations à peu près toute les secondes et donc en temps réel.
Bon je ne vais pas m'etendre sur le temps reel (je ne vois meme pas comment cela pourrait etre faisable surtout en utilisant HTTP, m'enfin passons).
Concernant cette histoire de recuperations multiples et simultanees cela ressemble a s'y meprendre a des pools de connexions telles que generallement implementees dans les serveurs d'applications type J2EE. Peut-etre une piste a explorer ?
je n'ose pas imaginer la charge induite sur les serveurs en question si ton programme se met a "requeter" toutes les secondes... (tu les as prevenus au moins ?).
Xavier
At Wed, 13 May 2009 20:44:05 -0700 (PDT),
Shakan wrote:
J'ai donc codé un client HTTP qui récupère les informations sur un
site boursier le problème étant que je souhaite récupérer ces même
informations pour plusieurs titres boursiers et cela au même moment
avec un temps de latence le plus réduit que possible entre chaque
requête afin d'être sur de capturer toutes les informations à peu près
toute les secondes et donc en temps réel.
Bon je ne vais pas m'etendre sur le temps reel (je ne vois meme pas
comment cela pourrait etre faisable surtout en utilisant HTTP, m'enfin
passons).
Concernant cette histoire de recuperations multiples et simultanees
cela ressemble a s'y meprendre a des pools de connexions telles que
generallement implementees dans les serveurs d'applications type
J2EE. Peut-etre une piste a explorer ?
je n'ose pas imaginer la charge induite sur les serveurs en question
si ton programme se met a "requeter" toutes les secondes... (tu les as
prevenus au moins ?).
At Wed, 13 May 2009 20:44:05 -0700 (PDT), Shakan wrote:
J'ai donc codé un client HTTP qui récupère les informations sur un site boursier le problème étant que je souhaite récupérer ces même informations pour plusieurs titres boursiers et cela au même moment avec un temps de latence le plus réduit que possible entre chaque requête afin d'être sur de capturer toutes les informations à peu près toute les secondes et donc en temps réel.
Bon je ne vais pas m'etendre sur le temps reel (je ne vois meme pas comment cela pourrait etre faisable surtout en utilisant HTTP, m'enfin passons).
Concernant cette histoire de recuperations multiples et simultanees cela ressemble a s'y meprendre a des pools de connexions telles que generallement implementees dans les serveurs d'applications type J2EE. Peut-etre une piste a explorer ?
je n'ose pas imaginer la charge induite sur les serveurs en question si ton programme se met a "requeter" toutes les secondes... (tu les as prevenus au moins ?).
Xavier
Shakan
On 14 mai, 19:23, Xavier Maillard wrote:
At Wed, 13 May 2009 20:44:05 -0700 (PDT),
Shakan wrote:
> J'ai donc codé un client HTTP qui récupère les informations sur u n > site boursier le problème étant que je souhaite récupérer ces m ême > informations pour plusieurs titres boursiers et cela au même moment > avec un temps de latence le plus réduit que possible entre chaque > requête afin d'être sur de capturer toutes les informations à peu près > toute les secondes et donc en temps réel.
Bon je ne vais pas m'etendre sur le temps reel (je ne vois meme pas comment cela pourrait etre faisable surtout en utilisant HTTP, m'enfin passons).
Concernant cette histoire de recuperations multiples et simultanees cela ressemble a s'y meprendre a des pools de connexions telles que generallement implementees dans les serveurs d'applications type J2EE. Peut-etre une piste a explorer ?
je n'ose pas imaginer la charge induite sur les serveurs en question si ton programme se met a "requeter" toutes les secondes... (tu les as prevenus au moins ?).
Xavier
En fait non je n'ai pas pas leur accord c'est franchement du web scraping que j'effectue dans le cadre de ce projet car l'autre solution était les web services mais il s'avère que pour récupérer des informations sensibles au moins toutes les secondes ce n'est pas la marche à suivre.
Je me suis renseigné sur les pools de threads mais je dois t'avouer que je ne suis pas sur que ca m'aide car il faudrait déjà que je comprenne les exemples de codes que j'ai trouvé et ce n'est pas chose aisé que de comprendre ces codes.
Bref comme tu dis ca m'étonnerait que le site acceptes plusieurs centaines de requêtes HTTP en même temps mais il faut savoir que quand plusieurs personnes consultent des pages sur le site ca revient un peu au même donc je ne pense pas que ca pose un réel problème de charge.
Enfin à toi de me dire ce que tu en penses et je te remercie pour ton aide.
On 14 mai, 19:23, Xavier Maillard <x...@gnu.org> wrote:
At Wed, 13 May 2009 20:44:05 -0700 (PDT),
Shakan wrote:
> J'ai donc codé un client HTTP qui récupère les informations sur u n
> site boursier le problème étant que je souhaite récupérer ces m ême
> informations pour plusieurs titres boursiers et cela au même moment
> avec un temps de latence le plus réduit que possible entre chaque
> requête afin d'être sur de capturer toutes les informations à peu près
> toute les secondes et donc en temps réel.
Bon je ne vais pas m'etendre sur le temps reel (je ne vois meme pas
comment cela pourrait etre faisable surtout en utilisant HTTP, m'enfin
passons).
Concernant cette histoire de recuperations multiples et simultanees
cela ressemble a s'y meprendre a des pools de connexions telles que
generallement implementees dans les serveurs d'applications type
J2EE. Peut-etre une piste a explorer ?
je n'ose pas imaginer la charge induite sur les serveurs en question
si ton programme se met a "requeter" toutes les secondes... (tu les as
prevenus au moins ?).
Xavier
En fait non je n'ai pas pas leur accord c'est franchement du web
scraping que j'effectue
dans le cadre de ce projet car l'autre solution était les web services
mais il s'avère
que pour récupérer des informations sensibles au moins toutes les
secondes ce n'est pas
la marche à suivre.
Je me suis renseigné sur les pools de threads mais je dois t'avouer
que je ne suis
pas sur que ca m'aide car il faudrait déjà que je comprenne les
exemples de codes que j'ai trouvé
et ce n'est pas chose aisé que de comprendre ces codes.
Bref comme tu dis ca m'étonnerait que le site acceptes plusieurs
centaines de requêtes HTTP en même temps
mais il faut savoir que quand plusieurs personnes consultent des pages
sur le site ca revient
un peu au même donc je ne pense pas que ca pose un réel problème de
charge.
Enfin à toi de me dire ce que tu en penses et je te remercie pour ton
aide.
> J'ai donc codé un client HTTP qui récupère les informations sur u n > site boursier le problème étant que je souhaite récupérer ces m ême > informations pour plusieurs titres boursiers et cela au même moment > avec un temps de latence le plus réduit que possible entre chaque > requête afin d'être sur de capturer toutes les informations à peu près > toute les secondes et donc en temps réel.
Bon je ne vais pas m'etendre sur le temps reel (je ne vois meme pas comment cela pourrait etre faisable surtout en utilisant HTTP, m'enfin passons).
Concernant cette histoire de recuperations multiples et simultanees cela ressemble a s'y meprendre a des pools de connexions telles que generallement implementees dans les serveurs d'applications type J2EE. Peut-etre une piste a explorer ?
je n'ose pas imaginer la charge induite sur les serveurs en question si ton programme se met a "requeter" toutes les secondes... (tu les as prevenus au moins ?).
Xavier
En fait non je n'ai pas pas leur accord c'est franchement du web scraping que j'effectue dans le cadre de ce projet car l'autre solution était les web services mais il s'avère que pour récupérer des informations sensibles au moins toutes les secondes ce n'est pas la marche à suivre.
Je me suis renseigné sur les pools de threads mais je dois t'avouer que je ne suis pas sur que ca m'aide car il faudrait déjà que je comprenne les exemples de codes que j'ai trouvé et ce n'est pas chose aisé que de comprendre ces codes.
Bref comme tu dis ca m'étonnerait que le site acceptes plusieurs centaines de requêtes HTTP en même temps mais il faut savoir que quand plusieurs personnes consultent des pages sur le site ca revient un peu au même donc je ne pense pas que ca pose un réel problème de charge.
Enfin à toi de me dire ce que tu en penses et je te remercie pour ton aide.
Bruno Desthuilliers
Méta-MCI (MVP) a écrit :
Bonjour !
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des aspects marketing ou propagandistes).
+1
Car : - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes.
Au delà de l'aspect "performance", une notion importante du temps réel est le "déterminisme" - en clair, le fait de savoir que telle action prendra un temps constant, quelque soit ce temps par ailleurs.
- passer par des sites boursiers, ça implique d'accepter les latences (internes) de ces sites. Et, ces latences peuvent être importantes (près de 20 minutes, pour certains sites connus).
Concernant les performances des threads en Python, elles sont largement suffisantes.
Mais ne permettrons pas forcément de tirer au mieux partie d'une machine multiprocesseur. Ceci étant :
Par contre, le point sensible, ce sera la (les ?) connexions Internet. Ainsi que la réactivité des sites/serveurs utilisés. Mais, là, ça ne dépend plus de toi...
CQFD.
Méta-MCI (MVP) a écrit :
Bonjour !
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en
dehors des aspects marketing ou propagandistes).
+1
Car :
- dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en
centièmes de secondes, voire en millièmes.
Au delà de l'aspect "performance", une notion importante du temps réel
est le "déterminisme" - en clair, le fait de savoir que telle action
prendra un temps constant, quelque soit ce temps par ailleurs.
- passer par des sites boursiers, ça implique d'accepter les latences
(internes) de ces sites. Et, ces latences peuvent être importantes (près
de 20 minutes, pour certains sites connus).
Concernant les performances des threads en Python, elles sont largement
suffisantes.
Mais ne permettrons pas forcément de tirer au mieux partie d'une machine
multiprocesseur. Ceci étant :
Par contre, le point sensible, ce sera la (les ?)
connexions Internet. Ainsi que la réactivité des sites/serveurs
utilisés. Mais, là, ça ne dépend plus de toi...
AMHA, l'expression "temps réel" ne s'applique pas à ton projet (en dehors des aspects marketing ou propagandistes).
+1
Car : - dans le temps réel, on ne raisonne pas en seconde(s), mais plutôt en centièmes de secondes, voire en millièmes.
Au delà de l'aspect "performance", une notion importante du temps réel est le "déterminisme" - en clair, le fait de savoir que telle action prendra un temps constant, quelque soit ce temps par ailleurs.
- passer par des sites boursiers, ça implique d'accepter les latences (internes) de ces sites. Et, ces latences peuvent être importantes (près de 20 minutes, pour certains sites connus).
Concernant les performances des threads en Python, elles sont largement suffisantes.
Mais ne permettrons pas forcément de tirer au mieux partie d'une machine multiprocesseur. Ceci étant :
Par contre, le point sensible, ce sera la (les ?) connexions Internet. Ainsi que la réactivité des sites/serveurs utilisés. Mais, là, ça ne dépend plus de toi...
