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 ?
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.
Ceci ne *peut* pas être garanti. Comme l'explicait Michel, ton programme dépendra de toutes façons des performances du réseau - donc des connections réseau de la machine sur laquelle il tourne, de la bande passante disponible à tous les niveaux, et bien sûr des temps de réaction des serveurs auprès desquels il va récupérer les infos...
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
A moins d'avoir plusieurs cartes réseau, je ne vois pas comment tu pourra envoyer plusieurs requêtes en parallèle. Et même si c'était le cas, les threads ne garantissent pas une exécution *réellement* "en parallèle" - ce n'est pas matériellement possible sur une machine monoprocesseur, et ce n'est pas logiciellement possible en CPython (avec des threads) en raison du GIL.
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 ?
Les threads ne sont pas la seule solution à la problématique de la concurrence. Et pas forcément la plus simple à mettre en oeuvre, accessoirement.
En tout état de cause, tout ce que tu peux garantir (et encore... sous réserve), c'est une latence de moins de deux secondes entre le lancement de deux chemins d'exécution concurrents. Après, tu dépends de ton matériel, de ton système, du réseau etc...
Shakan a écrit :
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.
Ceci ne *peut* pas être garanti. Comme l'explicait Michel, ton programme
dépendra de toutes façons des performances du réseau - donc des
connections réseau de la machine sur laquelle il tourne, de la bande
passante disponible à tous les niveaux, et bien sûr des temps de
réaction des serveurs auprès desquels il va récupérer les infos...
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
A moins d'avoir plusieurs cartes réseau, je ne vois pas comment tu
pourra envoyer plusieurs requêtes en parallèle. Et même si c'était le
cas, les threads ne garantissent pas une exécution *réellement* "en
parallèle" - ce n'est pas matériellement possible sur une machine
monoprocesseur, et ce n'est pas logiciellement possible en CPython (avec
des threads) en raison du GIL.
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 ?
Les threads ne sont pas la seule solution à la problématique de la
concurrence. Et pas forcément la plus simple à mettre en oeuvre,
accessoirement.
En tout état de cause, tout ce que tu peux garantir (et encore... sous
réserve), c'est une latence de moins de deux secondes entre le lancement
de deux chemins d'exécution concurrents. Après, tu dépends de ton
matériel, de ton système, du réseau etc...
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.
Ceci ne *peut* pas être garanti. Comme l'explicait Michel, ton programme dépendra de toutes façons des performances du réseau - donc des connections réseau de la machine sur laquelle il tourne, de la bande passante disponible à tous les niveaux, et bien sûr des temps de réaction des serveurs auprès desquels il va récupérer les infos...
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
A moins d'avoir plusieurs cartes réseau, je ne vois pas comment tu pourra envoyer plusieurs requêtes en parallèle. Et même si c'était le cas, les threads ne garantissent pas une exécution *réellement* "en parallèle" - ce n'est pas matériellement possible sur une machine monoprocesseur, et ce n'est pas logiciellement possible en CPython (avec des threads) en raison du GIL.
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 ?
Les threads ne sont pas la seule solution à la problématique de la concurrence. Et pas forcément la plus simple à mettre en oeuvre, accessoirement.
En tout état de cause, tout ce que tu peux garantir (et encore... sous réserve), c'est une latence de moins de deux secondes entre le lancement de deux chemins d'exécution concurrents. Après, tu dépends de ton matériel, de ton système, du réseau etc...
Bruno Desthuilliers
Shakan a écrit : (snip)
Bref comme tu dis ca m'étonnerait que le site acceptes plusieurs centaines de requêtes HTTP en même temps
Pour quelle définition de "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
Dans la pratique, il est rare qu'un internaute consultant un site rafraichisse la page toutes les secondes - ne serait-ce que parce le temps moyen de traitement (entre la récupération de la page et son affichage pas le navigateur) est généralement supérieur !-)
Bref, même les architectures prévues pour supporter des montées en charge importantes ont des limites sur le nombre de connections *simultanées* qu'elles peuvent supporter. Renseigne toi sur les attaques par déni de service...
donc je ne pense pas que ca pose un réel problème de charge.
A ta place, je n'en serai pas si sûr. Un robot d'indexation un peu indélicat (ou un peu trop "pressé") peut faire écrouler un serveur.
Shakan a écrit :
(snip)
Bref comme tu dis ca m'étonnerait que le site acceptes plusieurs
centaines de requêtes HTTP en même temps
Pour quelle définition de "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
Dans la pratique, il est rare qu'un internaute consultant un site
rafraichisse la page toutes les secondes - ne serait-ce que parce le
temps moyen de traitement (entre la récupération de la page et son
affichage pas le navigateur) est généralement supérieur !-)
Bref, même les architectures prévues pour supporter des montées en
charge importantes ont des limites sur le nombre de connections
*simultanées* qu'elles peuvent supporter. Renseigne toi sur les attaques
par déni de service...
donc je ne pense pas que ca pose un réel problème de
charge.
A ta place, je n'en serai pas si sûr. Un robot d'indexation un peu
indélicat (ou un peu trop "pressé") peut faire écrouler un serveur.
Bref comme tu dis ca m'étonnerait que le site acceptes plusieurs centaines de requêtes HTTP en même temps
Pour quelle définition de "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
Dans la pratique, il est rare qu'un internaute consultant un site rafraichisse la page toutes les secondes - ne serait-ce que parce le temps moyen de traitement (entre la récupération de la page et son affichage pas le navigateur) est généralement supérieur !-)
Bref, même les architectures prévues pour supporter des montées en charge importantes ont des limites sur le nombre de connections *simultanées* qu'elles peuvent supporter. Renseigne toi sur les attaques par déni de service...
donc je ne pense pas que ca pose un réel problème de charge.
A ta place, je n'en serai pas si sûr. Un robot d'indexation un peu indélicat (ou un peu trop "pressé") peut faire écrouler un serveur.
Xavier Maillard
At Thu, 14 May 2009 23:24:10 -0700 (PDT), Shakan wrote:
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.
Oui et non. Plusieurs centaines de connexions simultanées en provenance de plusieurs centaines/milliers d'utilisateurs (donc clients) ce n'est pas la même chose que *une seule et unique* personne faisant ces centaines de connexions.
Enfin à toi de me dire ce que tu en penses et je te remercie pour ton aide.
A titre perso, j'ai dit adieux a toutes ces histoires de polling que je trouve à la fois "has been" et hors de propos. En sus de gaspiller énormément de ressources (souvent en vain), je trouve ces mécanismes totalement inéfficaces.
Bon courage cependant ;)
Xavier
At Thu, 14 May 2009 23:24:10 -0700 (PDT),
Shakan wrote:
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.
Oui et non. Plusieurs centaines de connexions simultanées en
provenance de plusieurs centaines/milliers d'utilisateurs (donc
clients) ce n'est pas la même chose que *une seule et unique* personne
faisant ces centaines de connexions.
Enfin à toi de me dire ce que tu en penses et je te remercie pour ton
aide.
A titre perso, j'ai dit adieux a toutes ces histoires de polling que
je trouve à la fois "has been" et hors de propos. En sus de gaspiller
énormément de ressources (souvent en vain), je trouve ces mécanismes
totalement inéfficaces.
At Thu, 14 May 2009 23:24:10 -0700 (PDT), Shakan wrote:
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.
Oui et non. Plusieurs centaines de connexions simultanées en provenance de plusieurs centaines/milliers d'utilisateurs (donc clients) ce n'est pas la même chose que *une seule et unique* personne faisant ces centaines de connexions.
Enfin à toi de me dire ce que tu en penses et je te remercie pour ton aide.
A titre perso, j'ai dit adieux a toutes ces histoires de polling que je trouve à la fois "has been" et hors de propos. En sus de gaspiller énormément de ressources (souvent en vain), je trouve ces mécanismes totalement inéfficaces.
