|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||||
|
Invité(e)
Messages : n/a ![]() |
Salut à tous,
Avez-vous déjà essayé de compter le nombre d'insertion que PostgreSQL est apte à recevoir à la seconde? Pour ma part j'ai essayé avec Access et Python. J'ai crée une petite boucle qui va insérer 10000 fois mon nom dans un champ de table. Certes mon pc serveur n'est pas fortiche mais cela me permet de comparer les applications clientes. Mon serveur est équipé d'un sempron 2400 et de 512mo de ram. A noter que le disque dur est un disque de portable qui tourne à 4200trs/min (bref c pas le top) Mon réseau est constitué d'un routeur Netgear DG834G Voici le script en ADO( sous access) Code :
Code :
Code :
secondes Moyenne Enr/s ODBC 95 105 ADO(mdb) 47 212 ADO(mde) 47 212 Python 46 217 Python compilé en exe 46 217 Conclusion: Mon serveur est minable La faute n'est pas à Postgresql du moins je ne pense pas! J'ai testé en otant le réseau, c'est-à-dire en mettant les applications sur le pc serveur. Je gagne quelques secondes mais c'est pas extraordinaire. Je m'attendais à ce que Python fasse bcp mieux qu'access, en fait c'est identique. Autre chose, s'il faut éviter un mode de transfert de données, c'est bien ODBC. Certes la facilité est là mais bon… Quelqu'un a-t-il déjà essayé ce test? Quelle config faut-il pour passer à 1000 enregistrements par seconde? Quelles sont les limites de Postgresql? Ne dépend-il que du matériel qui le supporte? Merci pour vos commentaires. Dernière modification par jnore ; 07/01/2007 à 07h51. |
||||||
00
|
|
|
#2 | |
|
Expert Confirmé
![]() Inscription : septembre 2006 Messages : 2 291 ![]() |
Citation:
drôle de syntaxe sql… et un commit sans 'begin' ? un simple test - 8.0.3 sous FDC3, programme en C, accès à la DB via IP - localhost sur une config similaire (CP et RAM mais avec un disque IDE à 7200 T/min …) - donne pour 10000 insertions sur une table sans index ( "INSERT INTO commandes(nom) VALUES('JNO')" ) user 0m0.340s sys 0m0.310s soit 0.650 sec pour 10000 records ou 15384 records par seconde au niveau CPU… le temps réel perçu par l'utilisateur dépendra évidemment de la charge de la machine… (NB dans ce cas-ci l'utilisation de PREPARE n'apporte pas grand chose mais ce n'est pas nécessairement le cas de tous les INSERT…) |
|
|
|
00
|
|
|
#3 |
|
Invité(e)
Messages : n/a ![]() |
en vba il faut doubler les "" sinon ca ne fonctionne pas; Pareillement le
commandes correspond au schema Ceci dit comment fais-tu pour être aussi rapide? |
00
|
|
|
#4 | |
|
Expert Confirmé
![]() Inscription : septembre 2006 Messages : 2 291 ![]() |
Citation:
#include <libpq-fe.h> // cc -o testins -L/opt/local/lib -I/opt/local/include -lpq testins.c int main(int argc, char **argv) { int i ; PGconn *conn = PQconnectdb("YOUR_CONNECTION_STRING_HERE") ; if (PQstatus(conn) != CONNECTION_OK) { PQfinish(conn); fprintf(stderr, "# *** Can't connect to db\n") ; return 1 ; } for(i=0;i<10000;i++) { PGresult *result ; result = PQexec( conn, "INSERT INTO commandes(nom) VALUES('JNO')" ); PQclear(result) ; } PQfinish(conn); return 0 ; } |
|
|
|
00
|
|
|
#5 |
|
Invité(e)
Messages : n/a ![]() |
je ne connais pas trop ce langage mais comment calcules-tu ton temps entre le début des 10000 insertions et la fin?
J'ai l'impression que le délai que tu annoncais dans ton post précédent correspond à 1 insertion et non au temps d'insertion des 10000 Je me trompe? Merci de me répondre |
00
|
|
|
#6 | |
|
Expert Confirmé
![]() Inscription : septembre 2006 Messages : 2 291 ![]() |
Citation:
time ./testins user correspond au temps passé dans le code "utilisateur" du programme sys correspond au temps passé dans les appels "système" |
|
|
|
00
|
|
|
#7 | ||
|
Invité(e)
Messages : n/a ![]() |
J'ai crée une boucle d'insertion en pl/pgsql sur la meme table et le meme champ.....Ca n'a rien à voir!!!
J'insère 100 000 enregistrements en moins de 5s Par contre j'ai constaté que lorsque j'insère le meme nbre de données sur une table qui contient d'autres champ, cela ralentit le traitement!! Jusqu'à 6 fois dans mon cas!! voici le code Code :
|
||
00
|
Copyright © 2000-2012 - www.developpez.com