J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.
Il suffit donc de lancer chaque appel de fonction depuis des sessions
distinctes.
Cela implique de se passer de la "requête principale", mais, ça ne
parait pas trop grave.
J'ai ce genre de chose, je mets les appels de fonctions en cron, je les
cale aux heures souhaitées, en parallèle ( ou pas ).
Il suffit donc de lancer chaque appel de fonction depuis des sessions
distinctes.
Cela implique de se passer de la "requête principale", mais, ça ne
parait pas trop grave.
J'ai ce genre de chose, je mets les appels de fonctions en cron, je les
cale aux heures souhaitées, en parallèle ( ou pas ).
Il suffit donc de lancer chaque appel de fonction depuis des sessions
distinctes.
Cela implique de se passer de la "requête principale", mais, ça ne
parait pas trop grave.
J'ai ce genre de chose, je mets les appels de fonctions en cron, je les
cale aux heures souhaitées, en parallèle ( ou pas ).
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :
bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Voilà, j'espère que c'est un peu plus clair maintenant.
Le 14-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :Le 14/04/2010 14:31, Sebastien Lardiere a écrit :bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Ça, c'est plutôt normal. Je ne suis pas sûr qu'il existe des
mécanismes avancés de gestion des fils d'exécution dans les
spécifications SQL.Voilà, j'espère que c'est un peu plus clair maintenant.
Pas beaucoup plus, mais je me risque. Si j'ai bien compris (ce dont
je doute un peu), vous avez une fonction qui appelle plusieurs sous
fonctions. En partant du principe que toutes les fonctions ne
prennent en entrée qu'un seul enregistrement, vous pouvez donc
effectuer deux traitements en parallèle, l'un sur la première moitié
de vos enregistrements, l'autre sur la seconde, voire de scripter la
chose pour lancer autant de requêtes que vous appelez RQPrincipale
en parallèle qu'il y a de processeurs. Tous les serveurs de base de
données savent faire cela. Votre problème est donc plus au niveau de
votre outil lançant les requêtes que du côté du serveur de base
(pour ce que j'en ai compris).
Je ne connais pas HeidiSQL, je viens juste de jeter un oeil. J'ai
l'affreuse impression que cet outil ne vous permettra pas de faire
ce que vous voulez. Ce dont vous avez besoin, c'est soit d'une
routine de plus haut niveau capable d'exécuter plusieurs fils en
parallèle, soit de scripter le tout avec une langage de script
capable de lancer plusieurs requêtes en parallèle.
Au hasard :
#!/usr/local/bin/rpl -csp
// http://www.rpl2.fr
MAIN
<<
16 "/semaphore" crsmphr
{ } //<- paramètres de connexion au serveur sql
sqlconnect
-> SEMAPHORE CONNECTEUR
<<
"requête récupérant les enregistrements"
sqlquery
-> ENREGISTREMENTS
<<
while
ENREGISTREMENTS size 0>
repeat
SEMAPHORE smphrdecr
"appel à RQprincipale avec l'enregistrement "
ENREGISTREMENTS 1 get ->str +
CONNECTEUR
sqlquery
drop //<- résultat non pertinent
SEMAPHORE smphrincr
ENREGISTREMENTS tail
'ENREGISTREMENTS' sto
end
>>
CONNECTEUR sqldisconnect
SEMAPHORE clrsmphr
>>
Ce n'est pas optimal du tout (si le nombre d'enregistrements est
grand, il faut peut-être passer par autre chose qu'une liste pour
ENREGISTREMENTS), mais ça devrait fonctionner. Vous pouvez remplacer
ce langage par n'importe quel langage capable d'utiliser plusieurs
fils d'exécution.
En gros, l'idée est de lancer autant de RQprincipale en parallèle
qu'il y a de processeurs (ici 16) et de continuer tant qu'il reste
des enregistrements à traiter. Chaque RQprincipale s'exécute
séquentiellement sur un processeur, mais tous les processeurs
seront utilisés.
Cordialement,
JKB
Le 14-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :
bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Ça, c'est plutôt normal. Je ne suis pas sûr qu'il existe des
mécanismes avancés de gestion des fils d'exécution dans les
spécifications SQL.
Voilà, j'espère que c'est un peu plus clair maintenant.
Pas beaucoup plus, mais je me risque. Si j'ai bien compris (ce dont
je doute un peu), vous avez une fonction qui appelle plusieurs sous
fonctions. En partant du principe que toutes les fonctions ne
prennent en entrée qu'un seul enregistrement, vous pouvez donc
effectuer deux traitements en parallèle, l'un sur la première moitié
de vos enregistrements, l'autre sur la seconde, voire de scripter la
chose pour lancer autant de requêtes que vous appelez RQPrincipale
en parallèle qu'il y a de processeurs. Tous les serveurs de base de
données savent faire cela. Votre problème est donc plus au niveau de
votre outil lançant les requêtes que du côté du serveur de base
(pour ce que j'en ai compris).
Je ne connais pas HeidiSQL, je viens juste de jeter un oeil. J'ai
l'affreuse impression que cet outil ne vous permettra pas de faire
ce que vous voulez. Ce dont vous avez besoin, c'est soit d'une
routine de plus haut niveau capable d'exécuter plusieurs fils en
parallèle, soit de scripter le tout avec une langage de script
capable de lancer plusieurs requêtes en parallèle.
Au hasard :
#!/usr/local/bin/rpl -csp
// http://www.rpl2.fr
MAIN
<<
16 "/semaphore" crsmphr
{ } //<- paramètres de connexion au serveur sql
sqlconnect
-> SEMAPHORE CONNECTEUR
<<
"requête récupérant les enregistrements"
sqlquery
-> ENREGISTREMENTS
<<
while
ENREGISTREMENTS size 0>
repeat
SEMAPHORE smphrdecr
"appel à RQprincipale avec l'enregistrement "
ENREGISTREMENTS 1 get ->str +
CONNECTEUR
sqlquery
drop //<- résultat non pertinent
SEMAPHORE smphrincr
ENREGISTREMENTS tail
'ENREGISTREMENTS' sto
end
>>
CONNECTEUR sqldisconnect
SEMAPHORE clrsmphr
>>
Ce n'est pas optimal du tout (si le nombre d'enregistrements est
grand, il faut peut-être passer par autre chose qu'une liste pour
ENREGISTREMENTS), mais ça devrait fonctionner. Vous pouvez remplacer
ce langage par n'importe quel langage capable d'utiliser plusieurs
fils d'exécution.
En gros, l'idée est de lancer autant de RQprincipale en parallèle
qu'il y a de processeurs (ici 16) et de continuer tant qu'il reste
des enregistrements à traiter. Chaque RQprincipale s'exécute
séquentiellement sur un processeur, mais tous les processeurs
seront utilisés.
Cordialement,
JKB
Le 14-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :Le 14/04/2010 14:31, Sebastien Lardiere a écrit :bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Ça, c'est plutôt normal. Je ne suis pas sûr qu'il existe des
mécanismes avancés de gestion des fils d'exécution dans les
spécifications SQL.Voilà, j'espère que c'est un peu plus clair maintenant.
Pas beaucoup plus, mais je me risque. Si j'ai bien compris (ce dont
je doute un peu), vous avez une fonction qui appelle plusieurs sous
fonctions. En partant du principe que toutes les fonctions ne
prennent en entrée qu'un seul enregistrement, vous pouvez donc
effectuer deux traitements en parallèle, l'un sur la première moitié
de vos enregistrements, l'autre sur la seconde, voire de scripter la
chose pour lancer autant de requêtes que vous appelez RQPrincipale
en parallèle qu'il y a de processeurs. Tous les serveurs de base de
données savent faire cela. Votre problème est donc plus au niveau de
votre outil lançant les requêtes que du côté du serveur de base
(pour ce que j'en ai compris).
Je ne connais pas HeidiSQL, je viens juste de jeter un oeil. J'ai
l'affreuse impression que cet outil ne vous permettra pas de faire
ce que vous voulez. Ce dont vous avez besoin, c'est soit d'une
routine de plus haut niveau capable d'exécuter plusieurs fils en
parallèle, soit de scripter le tout avec une langage de script
capable de lancer plusieurs requêtes en parallèle.
Au hasard :
#!/usr/local/bin/rpl -csp
// http://www.rpl2.fr
MAIN
<<
16 "/semaphore" crsmphr
{ } //<- paramètres de connexion au serveur sql
sqlconnect
-> SEMAPHORE CONNECTEUR
<<
"requête récupérant les enregistrements"
sqlquery
-> ENREGISTREMENTS
<<
while
ENREGISTREMENTS size 0>
repeat
SEMAPHORE smphrdecr
"appel à RQprincipale avec l'enregistrement "
ENREGISTREMENTS 1 get ->str +
CONNECTEUR
sqlquery
drop //<- résultat non pertinent
SEMAPHORE smphrincr
ENREGISTREMENTS tail
'ENREGISTREMENTS' sto
end
>>
CONNECTEUR sqldisconnect
SEMAPHORE clrsmphr
>>
Ce n'est pas optimal du tout (si le nombre d'enregistrements est
grand, il faut peut-être passer par autre chose qu'une liste pour
ENREGISTREMENTS), mais ça devrait fonctionner. Vous pouvez remplacer
ce langage par n'importe quel langage capable d'utiliser plusieurs
fils d'exécution.
En gros, l'idée est de lancer autant de RQprincipale en parallèle
qu'il y a de processeurs (ici 16) et de continuer tant qu'il reste
des enregistrements à traiter. Chaque RQprincipale s'exécute
séquentiellement sur un processeur, mais tous les processeurs
seront utilisés.
Cordialement,
JKB
Le 14/04/2010 16:48, Sebastien Lardiere a écrit :
Il suffit donc de lancer chaque appel de fonction depuis des sessions
distinctes.
Cela implique de se passer de la "requête principale", mais, ça ne
parait pas trop grave.
J'ai ce genre de chose, je mets les appels de fonctions en cron, je les
cale aux heures souhaitées, en parallèle ( ou pas ).
Très bonne idée que de passer par le cron, je n'y avais pas pensé... Ca
résout une partie de mon problème, il ne me restera plus que des
fonctions simples (addition, multiplication) a exécuter dans le corps de
la requête --> donc des temps d'exécution très corrects.
En faisant ce genre de manipulation (calculs via crontab), on s'approche
des "materialized view" de Oracle si je ne m'abuse ???
Le 14/04/2010 16:48, Sebastien Lardiere a écrit :
Il suffit donc de lancer chaque appel de fonction depuis des sessions
distinctes.
Cela implique de se passer de la "requête principale", mais, ça ne
parait pas trop grave.
J'ai ce genre de chose, je mets les appels de fonctions en cron, je les
cale aux heures souhaitées, en parallèle ( ou pas ).
Très bonne idée que de passer par le cron, je n'y avais pas pensé... Ca
résout une partie de mon problème, il ne me restera plus que des
fonctions simples (addition, multiplication) a exécuter dans le corps de
la requête --> donc des temps d'exécution très corrects.
En faisant ce genre de manipulation (calculs via crontab), on s'approche
des "materialized view" de Oracle si je ne m'abuse ???
Le 14/04/2010 16:48, Sebastien Lardiere a écrit :
Il suffit donc de lancer chaque appel de fonction depuis des sessions
distinctes.
Cela implique de se passer de la "requête principale", mais, ça ne
parait pas trop grave.
J'ai ce genre de chose, je mets les appels de fonctions en cron, je les
cale aux heures souhaitées, en parallèle ( ou pas ).
Très bonne idée que de passer par le cron, je n'y avais pas pensé... Ca
résout une partie de mon problème, il ne me restera plus que des
fonctions simples (addition, multiplication) a exécuter dans le corps de
la requête --> donc des temps d'exécution très corrects.
En faisant ce genre de manipulation (calculs via crontab), on s'approche
des "materialized view" de Oracle si je ne m'abuse ???
Le 15/04/2010 09:39, JKB a écrit :Le 14-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :Le 14/04/2010 14:31, Sebastien Lardiere a écrit :bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Ça, c'est plutôt normal. Je ne suis pas sûr qu'il existe des
mécanismes avancés de gestion des fils d'exécution dans les
spécifications SQL.Voilà, j'espère que c'est un peu plus clair maintenant.
Pas beaucoup plus, mais je me risque. Si j'ai bien compris (ce dont
je doute un peu), vous avez une fonction qui appelle plusieurs sous
fonctions. En partant du principe que toutes les fonctions ne
prennent en entrée qu'un seul enregistrement, vous pouvez donc
effectuer deux traitements en parallèle, l'un sur la première moitié
de vos enregistrements, l'autre sur la seconde, voire de scripter la
chose pour lancer autant de requêtes que vous appelez RQPrincipale
en parallèle qu'il y a de processeurs. Tous les serveurs de base de
données savent faire cela. Votre problème est donc plus au niveau de
votre outil lançant les requêtes que du côté du serveur de base
(pour ce que j'en ai compris).
Je ne connais pas HeidiSQL, je viens juste de jeter un oeil. J'ai
l'affreuse impression que cet outil ne vous permettra pas de faire
ce que vous voulez. Ce dont vous avez besoin, c'est soit d'une
routine de plus haut niveau capable d'exécuter plusieurs fils en
parallèle, soit de scripter le tout avec une langage de script
capable de lancer plusieurs requêtes en parallèle.
Au hasard :
#!/usr/local/bin/rpl -csp
// http://www.rpl2.fr
MAIN
<<
16 "/semaphore" crsmphr
{ } //<- paramètres de connexion au serveur sql
sqlconnect
-> SEMAPHORE CONNECTEUR
<<
"requête récupérant les enregistrements"
sqlquery
-> ENREGISTREMENTS
<<
while
ENREGISTREMENTS size 0>
repeat
SEMAPHORE smphrdecr
"appel à RQprincipale avec l'enregistrement "
ENREGISTREMENTS 1 get ->str +
CONNECTEUR
sqlquery
drop //<- résultat non pertinent
SEMAPHORE smphrincr
ENREGISTREMENTS tail
'ENREGISTREMENTS' sto
end
>>
CONNECTEUR sqldisconnect
SEMAPHORE clrsmphr
>>
Ce n'est pas optimal du tout (si le nombre d'enregistrements est
grand, il faut peut-être passer par autre chose qu'une liste pour
ENREGISTREMENTS), mais ça devrait fonctionner. Vous pouvez remplacer
ce langage par n'importe quel langage capable d'utiliser plusieurs
fils d'exécution.
En gros, l'idée est de lancer autant de RQprincipale en parallèle
qu'il y a de processeurs (ici 16) et de continuer tant qu'il reste
des enregistrements à traiter. Chaque RQprincipale s'exécute
séquentiellement sur un processeur, mais tous les processeurs
seront utilisés.
Cordialement,
JKB
Ce que vous décrivez 'est exactement ce à quoi je pense !
Avant de me lancer dans le codage d'un script/application (en python par
exemple, si l'exécution en // est simple à programmer, ce sont des
threads ils me semble), je cherchais si il existe un moyen de faire
"plus simple", mais visiblement, pas de possibilité directement au
niveau de mySQL.
Le 15/04/2010 09:39, JKB a écrit :
Le 14-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :
Le 14/04/2010 14:31, Sebastien Lardiere a écrit :
bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Ça, c'est plutôt normal. Je ne suis pas sûr qu'il existe des
mécanismes avancés de gestion des fils d'exécution dans les
spécifications SQL.
Voilà, j'espère que c'est un peu plus clair maintenant.
Pas beaucoup plus, mais je me risque. Si j'ai bien compris (ce dont
je doute un peu), vous avez une fonction qui appelle plusieurs sous
fonctions. En partant du principe que toutes les fonctions ne
prennent en entrée qu'un seul enregistrement, vous pouvez donc
effectuer deux traitements en parallèle, l'un sur la première moitié
de vos enregistrements, l'autre sur la seconde, voire de scripter la
chose pour lancer autant de requêtes que vous appelez RQPrincipale
en parallèle qu'il y a de processeurs. Tous les serveurs de base de
données savent faire cela. Votre problème est donc plus au niveau de
votre outil lançant les requêtes que du côté du serveur de base
(pour ce que j'en ai compris).
Je ne connais pas HeidiSQL, je viens juste de jeter un oeil. J'ai
l'affreuse impression que cet outil ne vous permettra pas de faire
ce que vous voulez. Ce dont vous avez besoin, c'est soit d'une
routine de plus haut niveau capable d'exécuter plusieurs fils en
parallèle, soit de scripter le tout avec une langage de script
capable de lancer plusieurs requêtes en parallèle.
Au hasard :
#!/usr/local/bin/rpl -csp
// http://www.rpl2.fr
MAIN
<<
16 "/semaphore" crsmphr
{ } //<- paramètres de connexion au serveur sql
sqlconnect
-> SEMAPHORE CONNECTEUR
<<
"requête récupérant les enregistrements"
sqlquery
-> ENREGISTREMENTS
<<
while
ENREGISTREMENTS size 0>
repeat
SEMAPHORE smphrdecr
"appel à RQprincipale avec l'enregistrement "
ENREGISTREMENTS 1 get ->str +
CONNECTEUR
sqlquery
drop //<- résultat non pertinent
SEMAPHORE smphrincr
ENREGISTREMENTS tail
'ENREGISTREMENTS' sto
end
>>
CONNECTEUR sqldisconnect
SEMAPHORE clrsmphr
>>
Ce n'est pas optimal du tout (si le nombre d'enregistrements est
grand, il faut peut-être passer par autre chose qu'une liste pour
ENREGISTREMENTS), mais ça devrait fonctionner. Vous pouvez remplacer
ce langage par n'importe quel langage capable d'utiliser plusieurs
fils d'exécution.
En gros, l'idée est de lancer autant de RQprincipale en parallèle
qu'il y a de processeurs (ici 16) et de continuer tant qu'il reste
des enregistrements à traiter. Chaque RQprincipale s'exécute
séquentiellement sur un processeur, mais tous les processeurs
seront utilisés.
Cordialement,
JKB
Ce que vous décrivez 'est exactement ce à quoi je pense !
Avant de me lancer dans le codage d'un script/application (en python par
exemple, si l'exécution en // est simple à programmer, ce sont des
threads ils me semble), je cherchais si il existe un moyen de faire
"plus simple", mais visiblement, pas de possibilité directement au
niveau de mySQL.
Le 15/04/2010 09:39, JKB a écrit :Le 14-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul user ?,
Jerome PAULIN ?crivait dans fr.comp.applications.sgbd :Le 14/04/2010 14:31, Sebastien Lardiere a écrit :bonjour,
entre 500 et 1000 req/sec, lancées depuis un éditeur de requêtes ?
surprenant, non ?
Que cherchez-vous à résoudre exactement ?
Si chacune de vos requêtes va suffisamment vite, pourquoi chercher à
tout prix à utiliser plusieurs cores ? Ça serait une solution à quoi,
exactement ?
De plus, pouvez-vous répondre précisément à la question de JKB, qui ne
vous demande pas si vous savez lancer 2 requêtes simultanément ( mauvais
outil, changer d'outil ) , mais si c'est juste, fonctionnellement
parlant ? C'est-à-dire, est-ce que toutes ces requêtes dépendent les
unes des autres, et doivent être faites séquentiellement ?
Cordialement,
Bonjour,
J'ai dû mal m'exprimer, aussi je recommence en essayant d'être le plus
claire possible :
- ma base de données contient plusieurs fonctions, qui executent chacune
un ensemble de requêtes (il s'agit principalement de retrouver des
historiques). Ces fonctions ne sont pas interdépendantes et pourraient
être lancées en //.
- ma requete principale appelle ces fonctions pour un ensemble
d'enregistrements puis effectue un filtrage sur les resultats
Aujourd'hui le fonctionnement est le suivant :
RQPrincipale --> appel fn1 --> appel fn2 --> appel fn3 --> passage à
l'enregistrement suivant
ce que je recherche :
RQprincipale --> appel fn1 --> passage enreg suivant
--> appel fn2
--> appel fn3
Quand je parle de 500 à 1000 req/s, ceci correspond aux requêtes lancées
par les fonction, mais malheureusement sur un seul coeur.
Ça, c'est plutôt normal. Je ne suis pas sûr qu'il existe des
mécanismes avancés de gestion des fils d'exécution dans les
spécifications SQL.Voilà, j'espère que c'est un peu plus clair maintenant.
Pas beaucoup plus, mais je me risque. Si j'ai bien compris (ce dont
je doute un peu), vous avez une fonction qui appelle plusieurs sous
fonctions. En partant du principe que toutes les fonctions ne
prennent en entrée qu'un seul enregistrement, vous pouvez donc
effectuer deux traitements en parallèle, l'un sur la première moitié
de vos enregistrements, l'autre sur la seconde, voire de scripter la
chose pour lancer autant de requêtes que vous appelez RQPrincipale
en parallèle qu'il y a de processeurs. Tous les serveurs de base de
données savent faire cela. Votre problème est donc plus au niveau de
votre outil lançant les requêtes que du côté du serveur de base
(pour ce que j'en ai compris).
Je ne connais pas HeidiSQL, je viens juste de jeter un oeil. J'ai
l'affreuse impression que cet outil ne vous permettra pas de faire
ce que vous voulez. Ce dont vous avez besoin, c'est soit d'une
routine de plus haut niveau capable d'exécuter plusieurs fils en
parallèle, soit de scripter le tout avec une langage de script
capable de lancer plusieurs requêtes en parallèle.
Au hasard :
#!/usr/local/bin/rpl -csp
// http://www.rpl2.fr
MAIN
<<
16 "/semaphore" crsmphr
{ } //<- paramètres de connexion au serveur sql
sqlconnect
-> SEMAPHORE CONNECTEUR
<<
"requête récupérant les enregistrements"
sqlquery
-> ENREGISTREMENTS
<<
while
ENREGISTREMENTS size 0>
repeat
SEMAPHORE smphrdecr
"appel à RQprincipale avec l'enregistrement "
ENREGISTREMENTS 1 get ->str +
CONNECTEUR
sqlquery
drop //<- résultat non pertinent
SEMAPHORE smphrincr
ENREGISTREMENTS tail
'ENREGISTREMENTS' sto
end
>>
CONNECTEUR sqldisconnect
SEMAPHORE clrsmphr
>>
Ce n'est pas optimal du tout (si le nombre d'enregistrements est
grand, il faut peut-être passer par autre chose qu'une liste pour
ENREGISTREMENTS), mais ça devrait fonctionner. Vous pouvez remplacer
ce langage par n'importe quel langage capable d'utiliser plusieurs
fils d'exécution.
En gros, l'idée est de lancer autant de RQprincipale en parallèle
qu'il y a de processeurs (ici 16) et de continuer tant qu'il reste
des enregistrements à traiter. Chaque RQprincipale s'exécute
séquentiellement sur un processeur, mais tous les processeurs
seront utilisés.
Cordialement,
JKB
Ce que vous décrivez 'est exactement ce à quoi je pense !
Avant de me lancer dans le codage d'un script/application (en python par
exemple, si l'exécution en // est simple à programmer, ce sont des
threads ils me semble), je cherchais si il existe un moyen de faire
"plus simple", mais visiblement, pas de possibilité directement au
niveau de mySQL.
Je ne pense pas. Pour Python, ma religion m'interdit de
l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais mieux
servi que par soi-même...)
JKB
Je ne pense pas. Pour Python, ma religion m'interdit de
l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais mieux
servi que par soi-même...)
JKB
Je ne pense pas. Pour Python, ma religion m'interdit de
l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais mieux
servi que par soi-même...)
JKB
Je ne pense pas. Pour Python, ma religion m'interdit de
l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais mieux
servi que par soi-même...)
JKB
Ça t'interdit pas mal de choses, ta religion ;) .
Je ne pense pas. Pour Python, ma religion m'interdit de
l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais mieux
servi que par soi-même...)
JKB
Ça t'interdit pas mal de choses, ta religion ;) .
Je ne pense pas. Pour Python, ma religion m'interdit de
l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais mieux
servi que par soi-même...)
JKB
Ça t'interdit pas mal de choses, ta religion ;) .
Le 15-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul
user ?, Yliur ?crivait dans fr.comp.applications.sgbd :
>
>> Je ne pense pas. Pour Python, ma religion m'interdit de
>> l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais
>> mieux servi que par soi-même...)
>>
>> JKB
>>
>
> Ça t'interdit pas mal de choses, ta religion ;) .
Il y a un certain nombre de raisons parfaitement techniques
et hors sujet ici qui font que je n'utiliserai _jamais_ un truc aussi
mal fichu que python. Et le truc mal fichu commence à la définition
des blocs par indentation. Je suis assez favorable à l'indentation,
mais en faire une obligation est une immense connerie dès que des
éditeurs se mélangent les pinceaux entre des espaces et des
tabulations !
JKB
Le 15-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul
user ?, Yliur ?crivait dans fr.comp.applications.sgbd :
>
>> Je ne pense pas. Pour Python, ma religion m'interdit de
>> l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais
>> mieux servi que par soi-même...)
>>
>> JKB
>>
>
> Ça t'interdit pas mal de choses, ta religion ;) .
Il y a un certain nombre de raisons parfaitement techniques
et hors sujet ici qui font que je n'utiliserai _jamais_ un truc aussi
mal fichu que python. Et le truc mal fichu commence à la définition
des blocs par indentation. Je suis assez favorable à l'indentation,
mais en faire une obligation est une immense connerie dès que des
éditeurs se mélangent les pinceaux entre des espaces et des
tabulations !
JKB
Le 15-04-2010, ? propos de
Re: Est ce que postgresql est plus performant que mysql avec un seul
user ?, Yliur ?crivait dans fr.comp.applications.sgbd :
>
>> Je ne pense pas. Pour Python, ma religion m'interdit de
>> l'utiliser donc je n'ai aucun avis (d'autant qu'on n'est jamais
>> mieux servi que par soi-même...)
>>
>> JKB
>>
>
> Ça t'interdit pas mal de choses, ta religion ;) .
Il y a un certain nombre de raisons parfaitement techniques
et hors sujet ici qui font que je n'utiliserai _jamais_ un truc aussi
mal fichu que python. Et le truc mal fichu commence à la définition
des blocs par indentation. Je suis assez favorable à l'indentation,
mais en faire une obligation est une immense connerie dès que des
éditeurs se mélangent les pinceaux entre des espaces et des
tabulations !
JKB
