Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que
guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et
30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau
socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de
la couche protocolaire applicative et doit décrypter les infos en temps
réel puis les insérer dans une base de donnée (ces deux infos. sont
importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent:
1) La base de donnée à ses limites quant aux nombre de connexions
simultanées possibles.
2) L'OS et son implémentation de Python (voir un thread sur le Forum
anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000
sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à:
1) La mémoire
2) Le CPU
3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type:
1) Dois-je changer l'heure ?
2) As-tu une mise à jour de mon soft que je dois télécharger ?
3) Es-tu prêt à recevoir mes transactions ?
4) etc ....
_et_ que (les deux infos. préliminaires)
1) Je dois accéder à une base de donnée côté serveur
2) Je dois accéder à un HSM
(http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft.
style Zope ou autre m'aiderait grandement quant à la (désolé pour
l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de
gérer toutes les contraintes décrites ci-dessus ?
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à: 1) La mémoire 2) Le CPU 3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type: 1) Dois-je changer l'heure ? 2) As-tu une mise à jour de mon soft que je dois télécharger ? 3) Es-tu prêt à recevoir mes transactions ? 4) etc ....
_et_ que (les deux infos. préliminaires) 1) Je dois accéder à une base de donnée côté serveur 2) Je dois accéder à un HSM (http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft. style Zope ou autre m'aiderait grandement quant à la (désolé pour l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de gérer toutes les contraintes décrites ci-dessus ?
N'ayant guère d'expérience pratique (sur de vrais applis, j'entends) avec ces couches là d'un système client-serveur, je ne saurais te dire. Mais, à toutes fins utiles, a-tu regardé du côté de Twisted ?
Mes deux centimes...
Bonjour,
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que
guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et
30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau
socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de
la couche protocolaire applicative et doit décrypter les infos en temps
réel puis les insérer dans une base de donnée (ces deux infos. sont
importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent:
1) La base de donnée à ses limites quant aux nombre de connexions
simultanées possibles.
2) L'OS et son implémentation de Python (voir un thread sur le Forum
anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000
sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à:
1) La mémoire
2) Le CPU
3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type:
1) Dois-je changer l'heure ?
2) As-tu une mise à jour de mon soft que je dois télécharger ?
3) Es-tu prêt à recevoir mes transactions ?
4) etc ....
_et_ que (les deux infos. préliminaires)
1) Je dois accéder à une base de donnée côté serveur
2) Je dois accéder à un HSM
(http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft.
style Zope ou autre m'aiderait grandement quant à la (désolé pour
l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de
gérer toutes les contraintes décrites ci-dessus ?
N'ayant guère d'expérience pratique (sur de vrais applis, j'entends)
avec ces couches là d'un système client-serveur, je ne saurais te dire.
Mais, à toutes fins utiles, a-tu regardé du côté de Twisted ?
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à: 1) La mémoire 2) Le CPU 3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type: 1) Dois-je changer l'heure ? 2) As-tu une mise à jour de mon soft que je dois télécharger ? 3) Es-tu prêt à recevoir mes transactions ? 4) etc ....
_et_ que (les deux infos. préliminaires) 1) Je dois accéder à une base de donnée côté serveur 2) Je dois accéder à un HSM (http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft. style Zope ou autre m'aiderait grandement quant à la (désolé pour l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de gérer toutes les contraintes décrites ci-dessus ?
N'ayant guère d'expérience pratique (sur de vrais applis, j'entends) avec ces couches là d'un système client-serveur, je ne saurais te dire. Mais, à toutes fins utiles, a-tu regardé du côté de Twisted ?
Mes deux centimes...
William Dode
On 02-04-2007, hg wrote:
Bonjour,
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Est-ce que tu peux décider de l'ordre de connection des terminaux ou tu as déja de bonnes raisons de croire qu'ils vont tous se connecter en même temps ? Il faut déjà que tu estimes le nombre de connection simultanées réelles, en fonction de la durée des connections et de la probabilité qu'ils vont se connecter en même temps. C'est vraiment très rare d'avoir besoin d'un thread et d'une connection à une bdd sur une longue durée... Si c'était le cas tu as deux solution, soit gérer une file d'attente ou un serveur asynchrone.
Dans tous les cas l'idée c'est d'avoir des transactions les plus petites possibles pour donner l'illusion d'une simultanéité.
C'est quoi ton "architecture socket" exactement ?
Sinon, j'ai utilisé pyro récemment, bien que je n'ai aucune idée de la tenue en charge, c'est au moins d'une simplicité déconcertante, ça vaut le coup de faire ne serait-ce qu'un prototype. En consultant la liste des projets qui l'utilisent on peut penser que c'est assez performant.
http://pyro.sf.net
-- William Dodé - http://flibuste.net Développeur informatique indépendant
On 02-04-2007, hg wrote:
Bonjour,
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que
guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et
30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Est-ce que tu peux décider de l'ordre de connection des terminaux ou tu
as déja de bonnes raisons de croire qu'ils vont tous se connecter en
même temps ?
Il faut déjà que tu estimes le nombre de connection simultanées réelles,
en fonction de la durée des connections et de la probabilité qu'ils vont
se connecter en même temps. C'est vraiment très rare d'avoir besoin d'un
thread et d'une connection à une bdd sur une longue durée...
Si c'était le cas tu as deux solution, soit gérer une file d'attente ou
un serveur asynchrone.
Dans tous les cas l'idée c'est d'avoir des transactions les plus petites
possibles pour donner l'illusion d'une simultanéité.
C'est quoi ton "architecture socket" exactement ?
Sinon, j'ai utilisé pyro récemment, bien que je n'ai aucune idée de la
tenue en charge, c'est au moins d'une simplicité déconcertante, ça vaut
le coup de faire ne serait-ce qu'un prototype. En consultant la liste
des projets qui l'utilisent on peut penser que c'est assez performant.
http://pyro.sf.net
--
William Dodé - http://flibuste.net
Développeur informatique indépendant
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Est-ce que tu peux décider de l'ordre de connection des terminaux ou tu as déja de bonnes raisons de croire qu'ils vont tous se connecter en même temps ? Il faut déjà que tu estimes le nombre de connection simultanées réelles, en fonction de la durée des connections et de la probabilité qu'ils vont se connecter en même temps. C'est vraiment très rare d'avoir besoin d'un thread et d'une connection à une bdd sur une longue durée... Si c'était le cas tu as deux solution, soit gérer une file d'attente ou un serveur asynchrone.
Dans tous les cas l'idée c'est d'avoir des transactions les plus petites possibles pour donner l'illusion d'une simultanéité.
C'est quoi ton "architecture socket" exactement ?
Sinon, j'ai utilisé pyro récemment, bien que je n'ai aucune idée de la tenue en charge, c'est au moins d'une simplicité déconcertante, ça vaut le coup de faire ne serait-ce qu'un prototype. En consultant la liste des projets qui l'utilisent on peut penser que c'est assez performant.
http://pyro.sf.net
-- William Dodé - http://flibuste.net Développeur informatique indépendant
Laurent Pointal
hg wrote:
Bonjour,
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
AMA, comme Bruno:
==> twisted
De nombreux softs (ex. Zope) ont zappé leur couche réseau à eux pour switcher vers twisted.
http://twistedmatrix.com/trac/
Et y'a même un bouquin dessus.
http://www.oreilly.com/catalog/twistedadn/
Tu peux lire un des chapitres pour te faire une idée:
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que
guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements
et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau
socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge
de la couche protocolaire applicative et doit décrypter les infos en temps
réel puis les insérer dans une base de donnée (ces deux infos. sont
importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent:
1) La base de donnée à ses limites quant aux nombre de connexions
simultanées possibles.
2) L'OS et son implémentation de Python (voir un thread sur le Forum
anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et
~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
AMA, comme Bruno:
==> twisted
De nombreux softs (ex. Zope) ont zappé leur couche réseau à eux pour
switcher vers twisted.
http://twistedmatrix.com/trac/
Et y'a même un bouquin dessus.
http://www.oreilly.com/catalog/twistedadn/
Tu peux lire un des chapitres pour te faire une idée:
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
AMA, comme Bruno:
==> twisted
De nombreux softs (ex. Zope) ont zappé leur couche réseau à eux pour switcher vers twisted.
http://twistedmatrix.com/trac/
Et y'a même un bouquin dessus.
http://www.oreilly.com/catalog/twistedadn/
Tu peux lire un des chapitres pour te faire une idée:
S'il risque d'y avoir un nombre conséquent de connexions simultanées, je soutient la proposition de Bruno : Twisted-Matrix.
Au passage, je signale l'existence d'un livre sur Twisted-Matrix.
-- @-salutations
Michel Claveau
chris
Bonjour,
j'ai aussi lu les autres réponses
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
Mais je propose un autre axe de réflexion :
Si on est sur qu'un serveur peut gère environ de 300 à 1000 connexion avec du 32 Bits :
Surtout que dans ton cas il doit être possible de simuler ce genre d'applications
Alors le mieux est de prévoir une architecture multi tiers - un serveur de base de données (unique) - plusieurs serveurs d'applications
Après il suffit de répartir les connexions sur les différents serveurs et la plusieurs méthode existent
C'est du boulot mais vaux mieux l'appréhender avant que pendant
A+ chris
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Bonjour,
j'ai aussi lu les autres réponses
Deux contraintes techniques se présentent:
1) La base de donnée à ses limites quant aux nombre de connexions
simultanées possibles.
2) L'OS et son implémentation de Python (voir un thread sur le Forum
anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000
sur Windows ... et ce dans le cas d'un micro 32 bits.
Mais je propose un autre axe de réflexion :
Si on est sur qu'un serveur peut gère environ de 300 à 1000 connexion
avec du 32 Bits :
Surtout que dans ton cas il doit être possible de simuler ce genre
d'applications
Alors le mieux est de prévoir une architecture multi tiers
- un serveur de base de données (unique)
- plusieurs serveurs d'applications
Après il suffit de répartir les connexions sur les différents serveurs
et la plusieurs méthode existent
C'est du boulot mais vaux mieux l'appréhender avant que pendant
A+
chris
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
Mais je propose un autre axe de réflexion :
Si on est sur qu'un serveur peut gère environ de 300 à 1000 connexion avec du 32 Bits :
Surtout que dans ton cas il doit être possible de simuler ce genre d'applications
Alors le mieux est de prévoir une architecture multi tiers - un serveur de base de données (unique) - plusieurs serveurs d'applications
Après il suffit de répartir les connexions sur les différents serveurs et la plusieurs méthode existent
C'est du boulot mais vaux mieux l'appréhender avant que pendant
A+ chris
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
hg
hg wrote:
Bonjour,
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à: 1) La mémoire 2) Le CPU 3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type: 1) Dois-je changer l'heure ? 2) As-tu une mise à jour de mon soft que je dois télécharger ? 3) Es-tu prêt à recevoir mes transactions ? 4) etc ....
_et_ que (les deux infos. préliminaires) 1) Je dois accéder à une base de donnée côté serveur 2) Je dois accéder à un HSM (http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft. style Zope ou autre m'aiderait grandement quant à la (désolé pour l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de gérer toutes les contraintes décrites ci-dessus ?
Merci,
hg
Bonjour,
j'ai plein de réponses ... merci ... je tente de répondre à toutes:
J'ai effectivement démarré une telle simulation:
Par défault MySQL plante après 100 connexions simultanées: mon client me dit que c'est OK et que c'est une question de configuration.
En plus ma simu. pour l'instant lance le(s) client(s) et le serveur sur le même système.
Côté "threads", leurs serveurs tournent sur du 64 bits donc, a priori, le problème d'addressage (1000 sthread sur Win) devrait disparaitre.
Twisted: une boîte que je connais assez bien (www.zoto.com) l'utilise / mais n'étant pas un fana du web, je ne sais pas vraiment ce que ce truc apporte ... à chercher.
C'est quoi ton "architecture socket" exactement Chaque clietn se connecye au(x) serveur(s) par cette couche ... et ensuite
ma couche applicative prend le dessus?
...pyro .... Comme Twisted, j'y connais rien et dois faire mes devoirs.
hg
hg wrote:
Bonjour,
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que
guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements
et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau
socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge
de la couche protocolaire applicative et doit décrypter les infos en temps
réel puis les insérer dans une base de donnée (ces deux infos. sont
importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent:
1) La base de donnée à ses limites quant aux nombre de connexions
simultanées possibles.
2) L'OS et son implémentation de Python (voir un thread sur le Forum
anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et
~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à:
1) La mémoire
2) Le CPU
3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type:
1) Dois-je changer l'heure ?
2) As-tu une mise à jour de mon soft que je dois télécharger ?
3) Es-tu prêt à recevoir mes transactions ?
4) etc ....
_et_ que (les deux infos. préliminaires)
1) Je dois accéder à une base de donnée côté serveur
2) Je dois accéder à un HSM
(http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft.
style Zope ou autre m'aiderait grandement quant à la (désolé pour
l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de
gérer toutes les contraintes décrites ci-dessus ?
Merci,
hg
Bonjour,
j'ai plein de réponses ... merci ... je tente de répondre à toutes:
J'ai effectivement démarré une telle simulation:
Par défault MySQL plante après 100 connexions simultanées: mon client me dit
que c'est OK et que c'est une question de configuration.
En plus ma simu. pour l'instant lance le(s) client(s) et le serveur sur le
même système.
Côté "threads", leurs serveurs tournent sur du 64 bits donc, a priori, le
problème d'addressage (1000 sthread sur Win) devrait disparaitre.
Twisted: une boîte que je connais assez bien (www.zoto.com) l'utilise / mais
n'étant pas un fana du web, je ne sais pas vraiment ce que ce truc
apporte ... à chercher.
C'est quoi ton "architecture socket" exactement
Chaque clietn se connecye au(x) serveur(s) par cette couche ... et ensuite
ma couche applicative prend le dessus?
...pyro ....
Comme Twisted, j'y connais rien et dois faire mes devoirs.
Je ne pense pas avoir de vrai problème ... mais mieux vaut prévenir que guérir.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
Deux contraintes techniques se présentent: 1) La base de donnée à ses limites quant aux nombre de connexions simultanées possibles. 2) L'OS et son implémentation de Python (voir un thread sur le Forum anglo-saxon) donne une limite de ~300 threads simultanées sur *nix et ~1000 sur Windows ... et ce dans le cas d'un micro 32 bits.
D'après mes lectures, les deux contraintes ci-dessus sont liées à: 1) La mémoire 2) Le CPU 3) L'OS
Maintenant pour la question:
Sachant que les requêtes depuis chaque TPE vers le serveur sont du type: 1) Dois-je changer l'heure ? 2) As-tu une mise à jour de mon soft que je dois télécharger ? 3) Es-tu prêt à recevoir mes transactions ? 4) etc ....
_et_ que (les deux infos. préliminaires) 1) Je dois accéder à une base de donnée côté serveur 2) Je dois accéder à un HSM (http://en.wikipedia.org/wiki/Hardware_Security_Module) côté serveur
Mon architecture "socket" est-elle à votre avis une erreur ... et un soft. style Zope ou autre m'aiderait grandement quant à la (désolé pour l'anglissisme) "scalabitity" de mon architecture ... et me permettrait de gérer toutes les contraintes décrites ci-dessus ?
Merci,
hg
Bonjour,
j'ai plein de réponses ... merci ... je tente de répondre à toutes:
J'ai effectivement démarré une telle simulation:
Par défault MySQL plante après 100 connexions simultanées: mon client me dit que c'est OK et que c'est une question de configuration.
En plus ma simu. pour l'instant lance le(s) client(s) et le serveur sur le même système.
Côté "threads", leurs serveurs tournent sur du 64 bits donc, a priori, le problème d'addressage (1000 sthread sur Win) devrait disparaitre.
Twisted: une boîte que je connais assez bien (www.zoto.com) l'utilise / mais n'étant pas un fana du web, je ne sais pas vraiment ce que ce truc apporte ... à chercher.
C'est quoi ton "architecture socket" exactement Chaque clietn se connecye au(x) serveur(s) par cette couche ... et ensuite
ma couche applicative prend le dessus?
...pyro .... Comme Twisted, j'y connais rien et dois faire mes devoirs.
hg
Laurent Pointal
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Je ne sais pas où il a eu ces limites. Par contre, j'ai déjà vu passer des posts de personnes essayant de faire "trop" de threads et atteignant les limites du système hôte - rarement des problèmes de nombre maximum de threads en tant que tel, plus souvent des problèmes de mémoire alloué par thread et de capacité de la machine atteinte.
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Je ne sais pas où il a eu ces limites. Par contre, j'ai déjà vu passer
des posts de personnes essayant de faire "trop" de threads et atteignant
les limites du système hôte - rarement des problèmes de nombre maximum
de threads en tant que tel, plus souvent des problèmes de mémoire alloué
par thread et de capacité de la machine atteinte.
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Je ne sais pas où il a eu ces limites. Par contre, j'ai déjà vu passer des posts de personnes essayant de faire "trop" de threads et atteignant les limites du système hôte - rarement des problèmes de nombre maximum de threads en tant que tel, plus souvent des problèmes de mémoire alloué par thread et de capacité de la machine atteinte.
chris
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Je ne sais pas où il a eu ces limites. Par contre, j'ai déjà vu passer des posts de personnes essayant de faire "trop" de threads et atteignant les limites du système hôte - rarement des problèmes de nombre maximum de threads en tant que tel, plus souvent des problèmes de mémoire alloué par thread et de capacité de la machine atteinte.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
A+ chris
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Je ne sais pas où il a eu ces limites. Par contre, j'ai déjà vu passer
des posts de personnes essayant de faire "trop" de threads et atteignant
les limites du système hôte - rarement des problèmes de nombre maximum
de threads en tant que tel, plus souvent des problèmes de mémoire alloué
par thread et de capacité de la machine atteinte.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
REMARQUE : c'est quoi ton lien sur le nombre max de thread ?
Je ne sais pas où il a eu ces limites. Par contre, j'ai déjà vu passer des posts de personnes essayant de faire "trop" de threads et atteignant les limites du système hôte - rarement des problèmes de nombre maximum de threads en tant que tel, plus souvent des problèmes de mémoire alloué par thread et de capacité de la machine atteinte.
Oui de toutes façons si chaque thread prend 50 Mo de RAM x 1000 => BOUM
et 50 mo de nos jours c'est plus rien ...
A+ chris
bruno.desthuilliers
On 3 avr, 08:56, hg wrote: (snip)
Twisted: une boîte que je connais assez bien (www.zoto.com) l'utilise / mais n'étant pas un fana du web, je ne sais pas vraiment ce que ce truc apporte ... à chercher.
Twisted n'est pas spécifiquement lié au protocole HTTP, c'est un framework pour créer des serveurs asynchrones, éventuellement en définissant son propre protocole.
...pyro ....
Comme Twisted, j'y connais rien et dois faire mes devoirs.
pyro = "python remote objects". C'est un système de distribution d'objets pour Python, similaire (dans le principe) à Java/RMI ou Corba. Bon, c'est du Python donc plus light et plus simple quand même !-)
On 3 avr, 08:56, hg <h...@nospam.org> wrote:
(snip)
Twisted: une boîte que je connais assez bien (www.zoto.com) l'utilise / mais
n'étant pas un fana du web, je ne sais pas vraiment ce que ce truc
apporte ... à chercher.
Twisted n'est pas spécifiquement lié au protocole HTTP, c'est un
framework pour créer des serveurs asynchrones, éventuellement en
définissant son propre protocole.
...pyro ....
Comme Twisted, j'y connais rien et dois faire mes devoirs.
pyro = "python remote objects". C'est un système de distribution
d'objets pour Python, similaire (dans le principe) à Java/RMI ou
Corba. Bon, c'est du Python donc plus light et plus simple quand
même !-)
Twisted: une boîte que je connais assez bien (www.zoto.com) l'utilise / mais n'étant pas un fana du web, je ne sais pas vraiment ce que ce truc apporte ... à chercher.
Twisted n'est pas spécifiquement lié au protocole HTTP, c'est un framework pour créer des serveurs asynchrones, éventuellement en définissant son propre protocole.
...pyro ....
Comme Twisted, j'y connais rien et dois faire mes devoirs.
pyro = "python remote objects". C'est un système de distribution d'objets pour Python, similaire (dans le principe) à Java/RMI ou Corba. Bon, c'est du Python donc plus light et plus simple quand même !-)
hg
jean-michel bain-cornu wrote:
Bonsoir,
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Donc ... pas possible de passer des objets "pickled" hélas.
hg
jean-michel bain-cornu wrote:
Bonsoir,
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements
et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et
transmettent leurs transactions et récupèrent d'autres infos (heure
TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion
(niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se
charge de la couche protocolaire applicative et doit décrypter les infos
en temps réel puis les insérer dans une base de donnée (ces deux infos.
sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) :
quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe
du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en
C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Donc ... pas possible de passer des objets "pickled" hélas.
Mon client doit bientôt déployer un pilote de 200 terminaux de paiements et 30K cartes à puces.
A la fin de la journée, les "marchands" se connectent au serveur(s) et transmettent leurs transactions et récupèrent d'autres infos (heure TPE, ....)
Côté serveur, mon architecture est la suivante: à chaque connexion (niveau socket - Ethernet ou PPP), le soft serveur lance un thread qui se charge de la couche protocolaire applicative et doit décrypter les infos en temps réel puis les insérer dans une base de donnée (ces deux infos. sont importantes dans le cadre de ma question finale)
J'ai une question, sans doute très bête (aurais-je raté qqchose ?) : quel est l'OS sur les terminaux de paiement ?
Pas bête du tout: il y en a plusieurs selon les besoins du client: on passe du TPE à OS totalement propriétaire (ex: http://www.xiring.com/ ... codé en C) au "mini-pc" sur Windows ou *nix que je code en Python bien sûr.
Donc ... pas possible de passer des objets "pickled" hélas.
