Question sur la gestion "serveurs" en Python

Le
hg
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bruno Desthuilliers
Le #598236
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 ?

Mes deux centimes...

William Dode
Le #609816
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

Laurent Pointal
Le #609737
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:

http://www.oreilly.com/catalog/twistedadn/chapter/index.html

MC
Le #609736
Bonsoir !

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
Le #606474
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 ?

hg
Le #606473
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



Laurent Pointal
Le #606469

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
Le #606468

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
Le #606223
On 3 avr, 08:56, hg (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 !-)




hg
Le #606222
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


Publicité
Poster une réponse
Anonyme