Dans un logiciel (serveur, gérant des clients dans des threads
distincts), nous avons besoin d'un évaluateur d'expressions plutôt
simples (genre addition, concaténation et découage de chaînes de
caractères) . Pourquoi ne pas utiliser Python plutôt que de réinventer
la roue (analyser le texte de l'expression puis l'exécuter) ?
Je me pose des questions par rapport aux performances. Avec CPython, il y
a le verrou global de l'interpréteur qui risque de tuer les perfs. On ne
peut aussi avoir qu'un seul interpréteur par process (enfin, j'imagine
que celà n'a pas changé). Y-a-t-il un connaisseur de CPython pour
confirmer que c'est vraiment problématique ?
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre
"interpreter_handle" dans chaque fonction de CPython... Les variables
globales c'est mal.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
F. Petitjean
Bonjour,
Dans un logiciel (serveur, gérant des clients dans des threads distincts), nous avons besoin d'un évaluateur d'expressions plutôt simples (genre addition, concaténation et découage de chaînes de caractères) . Pourquoi ne pas utiliser Python plutôt que de réinventer la roue (analyser le texte de l'expression puis l'exécuter) ? Il faudrait nous dire d'où viennent ces expressions à évaluer et comment
les logiciels clients sont programmés (il arrive que les postes clients soient très puissants et si c'est en python l'évaluation d'une expression sur le poste client lui-même ne me semble pas la mer à boire).
Je me pose des questions par rapport aux performances. Avec CPython, il y a le verrou global de l'interpréteur qui risque de tuer les perfs. On ne peut aussi avoir qu'un seul interpréteur par process (enfin, j'imagine que celà n'a pas changé). Y-a-t-il un connaisseur de CPython pour confirmer que c'est vraiment problématique ? Jamais entendu un dicton informatique du genre « premature optimisation
is the root of all evils » ?
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre "interpreter_handle" dans chaque fonction de CPython... Les variables globales c'est mal. Faudrait nous en dire un peu plus sur l'architecture de votre
application : nombre de clients, temps de réponse attendus, volume et nature des transferts d'information ...
Merci de votre attention.
Bonjour,
Dans un logiciel (serveur, gérant des clients dans des threads
distincts), nous avons besoin d'un évaluateur d'expressions plutôt
simples (genre addition, concaténation et découage de chaînes de
caractères) . Pourquoi ne pas utiliser Python plutôt que de réinventer
la roue (analyser le texte de l'expression puis l'exécuter) ?
Il faudrait nous dire d'où viennent ces expressions à évaluer et comment
les logiciels clients sont programmés (il arrive que les postes clients
soient très puissants et si c'est en python l'évaluation d'une
expression sur le poste client lui-même ne me semble pas la mer à
boire).
Je me pose des questions par rapport aux performances. Avec CPython, il y
a le verrou global de l'interpréteur qui risque de tuer les perfs. On ne
peut aussi avoir qu'un seul interpréteur par process (enfin, j'imagine
que celà n'a pas changé). Y-a-t-il un connaisseur de CPython pour
confirmer que c'est vraiment problématique ?
Jamais entendu un dicton informatique du genre « premature optimisation
is the root of all evils » ?
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre
"interpreter_handle" dans chaque fonction de CPython... Les variables
globales c'est mal.
Faudrait nous en dire un peu plus sur l'architecture de votre
application : nombre de clients, temps de réponse attendus, volume et
nature des transferts d'information ...
Dans un logiciel (serveur, gérant des clients dans des threads distincts), nous avons besoin d'un évaluateur d'expressions plutôt simples (genre addition, concaténation et découage de chaînes de caractères) . Pourquoi ne pas utiliser Python plutôt que de réinventer la roue (analyser le texte de l'expression puis l'exécuter) ? Il faudrait nous dire d'où viennent ces expressions à évaluer et comment
les logiciels clients sont programmés (il arrive que les postes clients soient très puissants et si c'est en python l'évaluation d'une expression sur le poste client lui-même ne me semble pas la mer à boire).
Je me pose des questions par rapport aux performances. Avec CPython, il y a le verrou global de l'interpréteur qui risque de tuer les perfs. On ne peut aussi avoir qu'un seul interpréteur par process (enfin, j'imagine que celà n'a pas changé). Y-a-t-il un connaisseur de CPython pour confirmer que c'est vraiment problématique ? Jamais entendu un dicton informatique du genre « premature optimisation
is the root of all evils » ?
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre "interpreter_handle" dans chaque fonction de CPython... Les variables globales c'est mal. Faudrait nous en dire un peu plus sur l'architecture de votre
application : nombre de clients, temps de réponse attendus, volume et nature des transferts d'information ...
Merci de votre attention.
Roger That
Il faudrait nous dire d'où viennent ces expressions à évaluer et comment les logiciels clients sont programmés (il arrive que les postes clients soient très puissants et si c'est en python l'évaluation d'une expression sur le poste client lui-même ne me semble pas la mer à boire).
Les clients ne font aucun traitement, ils se contentent de remplir des formulaires, d'envoyer les données au serveur qui va les traiter puis d'afficher les résultats. Le serveur peut aussi être appelé par un autre serveur (autre cas d'utilisation). Il peut y avoir un grand nombre de clients (tous les opérateurs d'un gros établissement de niveau national, et si le pays c'est les Etats-Unis ça fait un paquet d'opérateurs). C'est donc hors de question d'avoir un verrou global vu le nombre d'évaluations pouvant être effectuées en parallèle (par les différentes sessions utilisateur).
Jamais entendu un dicton informatique du genre « premature optimisation is the root of all evils » ?
Je sais, mais choisir une architecture inadaptée mène de la même façon à la ruine.
D'un point de vue fonctionnalité, je pense que ça va (simplicité et possibilité d'ajouter facilement de nouvelles fonctions), mais si techniquement c'est inadapté on court à la catastrophe. Il y a un vaste choix de langage de script utilisable par un non-programmeur (pour créer des expressions), et parmis ceux-ci je cherche une solution adaptée techniquement à mon problème.
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre "interpreter_handle" dans chaque fonction de CPython... Les variables globales c'est mal.
Faudrait nous en dire un peu plus sur l'architecture de votre application : nombre de clients, temps de réponse attendus, volume et nature des transferts d'information ...
Grosso-modo, le serveur va recevoir pour chaque client/session un enregistrement contenant un certain nombre de champs (disons un millier, comme des adresses, des montants). Une partie des traitement sur ces données consiste à évaluer des expressions (écrites par des non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les utilisateurs des clients): - pour effectuer des opérations. ex: si age>18 alors sauver_dans_base_de_donnees - pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Il faudrait nous dire d'où viennent ces expressions à évaluer et comment
les logiciels clients sont programmés (il arrive que les postes clients
soient très puissants et si c'est en python l'évaluation d'une
expression sur le poste client lui-même ne me semble pas la mer à
boire).
Les clients ne font aucun traitement, ils se contentent de remplir des
formulaires, d'envoyer les données au serveur qui va les traiter puis
d'afficher les résultats. Le serveur peut aussi être appelé par un autre
serveur (autre cas d'utilisation).
Il peut y avoir un grand nombre de clients (tous les opérateurs d'un
gros établissement de niveau national, et si le pays c'est les
Etats-Unis ça fait un paquet d'opérateurs). C'est donc hors de question
d'avoir un verrou global vu le nombre d'évaluations pouvant être
effectuées en parallèle (par les différentes sessions utilisateur).
Jamais entendu un dicton informatique du genre « premature optimisation
is the root of all evils » ?
Je sais, mais choisir une architecture inadaptée mène de la même façon à
la ruine.
D'un point de vue fonctionnalité, je pense que ça va (simplicité et
possibilité d'ajouter facilement de nouvelles fonctions), mais si
techniquement c'est inadapté on court à la catastrophe. Il y a un vaste
choix de langage de script utilisable par un non-programmeur (pour créer
des expressions), et parmis ceux-ci je cherche une solution adaptée
techniquement à mon problème.
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre
"interpreter_handle" dans chaque fonction de CPython... Les variables
globales c'est mal.
Faudrait nous en dire un peu plus sur l'architecture de votre
application : nombre de clients, temps de réponse attendus, volume et
nature des transferts d'information ...
Grosso-modo, le serveur va recevoir pour chaque client/session un
enregistrement contenant un certain nombre de champs (disons un millier,
comme des adresses, des montants). Une partie des traitement sur ces
données consiste à évaluer des expressions (écrites par des
non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les
utilisateurs des clients):
- pour effectuer des opérations. ex: si age>18 alors
sauver_dans_base_de_donnees
- pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Il faudrait nous dire d'où viennent ces expressions à évaluer et comment les logiciels clients sont programmés (il arrive que les postes clients soient très puissants et si c'est en python l'évaluation d'une expression sur le poste client lui-même ne me semble pas la mer à boire).
Les clients ne font aucun traitement, ils se contentent de remplir des formulaires, d'envoyer les données au serveur qui va les traiter puis d'afficher les résultats. Le serveur peut aussi être appelé par un autre serveur (autre cas d'utilisation). Il peut y avoir un grand nombre de clients (tous les opérateurs d'un gros établissement de niveau national, et si le pays c'est les Etats-Unis ça fait un paquet d'opérateurs). C'est donc hors de question d'avoir un verrou global vu le nombre d'évaluations pouvant être effectuées en parallèle (par les différentes sessions utilisateur).
Jamais entendu un dicton informatique du genre « premature optimisation is the root of all evils » ?
Je sais, mais choisir une architecture inadaptée mène de la même façon à la ruine.
D'un point de vue fonctionnalité, je pense que ça va (simplicité et possibilité d'ajouter facilement de nouvelles fonctions), mais si techniquement c'est inadapté on court à la catastrophe. Il y a un vaste choix de langage de script utilisable par un non-programmeur (pour créer des expressions), et parmis ceux-ci je cherche une solution adaptée techniquement à mon problème.
Je ne comprends pas pourquoi ils n'ont pas mis un paramètre "interpreter_handle" dans chaque fonction de CPython... Les variables globales c'est mal.
Faudrait nous en dire un peu plus sur l'architecture de votre application : nombre de clients, temps de réponse attendus, volume et nature des transferts d'information ...
Grosso-modo, le serveur va recevoir pour chaque client/session un enregistrement contenant un certain nombre de champs (disons un millier, comme des adresses, des montants). Une partie des traitement sur ces données consiste à évaluer des expressions (écrites par des non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les utilisateurs des clients): - pour effectuer des opérations. ex: si age>18 alors sauver_dans_base_de_donnees - pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Wilk
Roger That <fabsk+ writes:
Grosso-modo, le serveur va recevoir pour chaque client/session un enregistrement contenant un certain nombre de champs (disons un millier, comme des adresses, des montants). Une partie des traitement sur ces données consiste à évaluer des expressions (écrites par des non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les utilisateurs des clients): - pour effectuer des opérations. ex: si age>18 alors sauver_dans_base_de_donnees - pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Si tu le laisse évaluer trop d'expressions tu risque d'avoir un problème de sécurité...
A part ça c'est simple, tu peux faire un bench facilement, tu verra que le problème viendra sûrement plus de la partie réseau que de l'évaluation des expressions :
a = 2 c = compile("if a<5: a=a*2","<string>","exec") exec(c) print a
Pour cette expression, sur un PIV, je l'évalue 25000x/seconde En gérant un cache des expressions déjà compilées, j'évalue les 25000 en 0.04s...
Ensuite, si tu as vraiment énormément de connections simultanées, tu aurras intérêt à utiliser un serveur asynchrone, avec un thread pour les accès en bdd et roule ma poule, en prime tu vas économiser sur le serveur (par rapport à une solution multithread).
-- William - http://flibuste.net
Roger That <fabsk+news@free.fr> writes:
Grosso-modo, le serveur va recevoir pour chaque client/session un
enregistrement contenant un certain nombre de champs (disons un
millier, comme des adresses, des montants). Une partie des traitement
sur ces données consiste à évaluer des expressions (écrites par des
non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les
utilisateurs des clients):
- pour effectuer des opérations. ex: si age>18 alors
sauver_dans_base_de_donnees
- pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Si tu le laisse évaluer trop d'expressions tu risque d'avoir un
problème de sécurité...
A part ça c'est simple, tu peux faire un bench facilement, tu verra que
le problème viendra sûrement plus de la partie réseau que de
l'évaluation des expressions :
a = 2
c = compile("if a<5: a=a*2","<string>","exec")
exec(c)
print a
Pour cette expression, sur un PIV, je l'évalue 25000x/seconde
En gérant un cache des expressions déjà compilées, j'évalue les 25000
en 0.04s...
Ensuite, si tu as vraiment énormément de connections simultanées, tu
aurras intérêt à utiliser un serveur asynchrone, avec un thread pour les
accès en bdd et roule ma poule, en prime tu vas économiser sur le
serveur (par rapport à une solution multithread).
Grosso-modo, le serveur va recevoir pour chaque client/session un enregistrement contenant un certain nombre de champs (disons un millier, comme des adresses, des montants). Une partie des traitement sur ces données consiste à évaluer des expressions (écrites par des non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les utilisateurs des clients): - pour effectuer des opérations. ex: si age>18 alors sauver_dans_base_de_donnees - pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Si tu le laisse évaluer trop d'expressions tu risque d'avoir un problème de sécurité...
A part ça c'est simple, tu peux faire un bench facilement, tu verra que le problème viendra sûrement plus de la partie réseau que de l'évaluation des expressions :
a = 2 c = compile("if a<5: a=a*2","<string>","exec") exec(c) print a
Pour cette expression, sur un PIV, je l'évalue 25000x/seconde En gérant un cache des expressions déjà compilées, j'évalue les 25000 en 0.04s...
Ensuite, si tu as vraiment énormément de connections simultanées, tu aurras intérêt à utiliser un serveur asynchrone, avec un thread pour les accès en bdd et roule ma poule, en prime tu vas économiser sur le serveur (par rapport à une solution multithread).
-- William - http://flibuste.net
Roger That
Roger That <fabsk+ writes:
Grosso-modo, le serveur va recevoir pour chaque client/session un enregistrement contenant un certain nombre de champs (disons un millier, comme des adresses, des montants). Une partie des traitement sur ces données consiste à évaluer des expressions (écrites par des non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les utilisateurs des clients): - pour effectuer des opérations. ex: si age>18 alors sauver_dans_base_de_donnees - pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Si tu le laisse évaluer trop d'expressions tu risque d'avoir un problème de sécurité...
Les programmes clients ne peuvent pas agir sur les expressions. Ils ne peuvent que remplir les données et appeler une action sur le serveur (dont ils ne connaissent pas le fonctionnement interne). Le développement comprend deux parties: - les logiciels de base écrit en C++ (serveur, outils de configuration) - la création d'un système avec la définition des données, les interfaces utilisateurs affichées par des clients, les traitements des données, le tout avec des outils développés en interne (pas de programmation avec du code proprement dit).
La définition des expressions ne pose pas plus de problème de sécurité que la définition de requêtes SQL je pense. J'imagine qu'il est possible de restreindre les possibilités comme dans Zope.
Pour cette expression, sur un PIV, je l'évalue 25000x/seconde En gérant un cache des expressions déjà compilées, j'évalue les 25000 en 0.04s...
Je vais faire mes propres tests, tu as peut-être raison, c'est peut-être négligeable. Il faudrait aussi calculer sur une machine SMP.
Ensuite, si tu as vraiment énormément de connections simultanées, tu aurras intérêt à utiliser un serveur asynchrone, avec un thread pour les accès en bdd et roule ma poule, en prime tu vas économiser sur le serveur (par rapport à une solution multithread).
L'architecture existe déjà et ne peut pas être changée (c'est un très gros programme). C'est un thread par client en cours de traitement (les requêtes des clients peuvent être mises en queue).
Pour la base de données c'était juste un exemple de fonctionnalité pouvant être appeler selon une condition. J'ai essayé d'éviter le superflux dans la description de mon problème.
Roger That <fabsk+news@free.fr> writes:
Grosso-modo, le serveur va recevoir pour chaque client/session un
enregistrement contenant un certain nombre de champs (disons un
millier, comme des adresses, des montants). Une partie des traitement
sur ces données consiste à évaluer des expressions (écrites par des
non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les
utilisateurs des clients):
- pour effectuer des opérations. ex: si age>18 alors
sauver_dans_base_de_donnees
- pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Si tu le laisse évaluer trop d'expressions tu risque d'avoir un
problème de sécurité...
Les programmes clients ne peuvent pas agir sur les expressions. Ils ne
peuvent que remplir les données et appeler une action sur le serveur
(dont ils ne connaissent pas le fonctionnement interne).
Le développement comprend deux parties:
- les logiciels de base écrit en C++ (serveur, outils de configuration)
- la création d'un système avec la définition des données, les
interfaces utilisateurs affichées par des clients, les traitements des
données, le tout avec des outils développés en interne (pas de
programmation avec du code proprement dit).
La définition des expressions ne pose pas plus de problème de sécurité
que la définition de requêtes SQL je pense. J'imagine qu'il est possible
de restreindre les possibilités comme dans Zope.
Pour cette expression, sur un PIV, je l'évalue 25000x/seconde
En gérant un cache des expressions déjà compilées, j'évalue les 25000
en 0.04s...
Je vais faire mes propres tests, tu as peut-être raison, c'est peut-être
négligeable. Il faudrait aussi calculer sur une machine SMP.
Ensuite, si tu as vraiment énormément de connections simultanées, tu
aurras intérêt à utiliser un serveur asynchrone, avec un thread pour les
accès en bdd et roule ma poule, en prime tu vas économiser sur le
serveur (par rapport à une solution multithread).
L'architecture existe déjà et ne peut pas être changée (c'est un très
gros programme). C'est un thread par client en cours de traitement (les
requêtes des clients peuvent être mises en queue).
Pour la base de données c'était juste un exemple de fonctionnalité
pouvant être appeler selon une condition. J'ai essayé d'éviter le
superflux dans la description de mon problème.
Grosso-modo, le serveur va recevoir pour chaque client/session un enregistrement contenant un certain nombre de champs (disons un millier, comme des adresses, des montants). Une partie des traitement sur ces données consiste à évaluer des expressions (écrites par des non-programmeurs qui mettent en oeuvre le système, ce ne sont pas les utilisateurs des clients): - pour effectuer des opérations. ex: si age>18 alors sauver_dans_base_de_donnees - pour calculer d'autres champs: montant_mensuel=montant_annuel/12.
Si tu le laisse évaluer trop d'expressions tu risque d'avoir un problème de sécurité...
Les programmes clients ne peuvent pas agir sur les expressions. Ils ne peuvent que remplir les données et appeler une action sur le serveur (dont ils ne connaissent pas le fonctionnement interne). Le développement comprend deux parties: - les logiciels de base écrit en C++ (serveur, outils de configuration) - la création d'un système avec la définition des données, les interfaces utilisateurs affichées par des clients, les traitements des données, le tout avec des outils développés en interne (pas de programmation avec du code proprement dit).
La définition des expressions ne pose pas plus de problème de sécurité que la définition de requêtes SQL je pense. J'imagine qu'il est possible de restreindre les possibilités comme dans Zope.
Pour cette expression, sur un PIV, je l'évalue 25000x/seconde En gérant un cache des expressions déjà compilées, j'évalue les 25000 en 0.04s...
Je vais faire mes propres tests, tu as peut-être raison, c'est peut-être négligeable. Il faudrait aussi calculer sur une machine SMP.
Ensuite, si tu as vraiment énormément de connections simultanées, tu aurras intérêt à utiliser un serveur asynchrone, avec un thread pour les accès en bdd et roule ma poule, en prime tu vas économiser sur le serveur (par rapport à une solution multithread).
L'architecture existe déjà et ne peut pas être changée (c'est un très gros programme). C'est un thread par client en cours de traitement (les requêtes des clients peuvent être mises en queue).
Pour la base de données c'était juste un exemple de fonctionnalité pouvant être appeler selon une condition. J'ai essayé d'éviter le superflux dans la description de mon problème.
