[WD8-9-10] Lenteur HF avec fichier (taille moyenne) en suppression
3 réponses
patrice
Bonjour
Je viens de constater une lenteur assez bizarre lors de la suppression
massive d'enregistrement.
J'utilise des fichiers temporaires , lié à un fichier de session.
(chaque fiche temporaire un un champ SESSIONID qui me permet de tout
supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo durait
30s et la suppression 6minutes!!!)
Apres moult investigations, je m'apercois qu'un truc style :
hlitrecherchepremier(TEMPO,SESSIONID,idsess)
tantque htrouve(TEMPO)
hsupprime(TEMPO)
hlitsuivant(TEMPO)
fin
dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du CPU
Alors que :
pour i=1 A hnbenr(TEMPO)
hlit(TEMPO,i)
si TEMPO.SESSIONID=idess alors
hsupprime(TEMPO)
fin
fin
sur le même fichier avec les mêmes données dure 45 secondes
Quelqu'un a t'il déjà observé cela ?
y a t-il un contournement ?
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
Pascal F
Après mure réflexion, patrice a écrit :
Bonjour
Je viens de constater une lenteur assez bizarre lors de la suppression massive d'enregistrement. J'utilise des fichiers temporaires , lié à un fichier de session. (chaque fiche temporaire un un champ SESSIONID qui me permet de tout supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo durait 30s et la suppression 6minutes!!!)
Apres moult investigations, je m'apercois qu'un truc style : hlitrecherchepremier(TEMPO,SESSIONID,idsess) tantque htrouve(TEMPO) hsupprime(TEMPO) hlitsuivant(TEMPO) fin dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du CPU
Alors que : pour i=1 A hnbenr(TEMPO) hlit(TEMPO,i) si TEMPO.SESSIONID=idess alors hsupprime(TEMPO) fin fin
sur le même fichier avec les mêmes données dure 45 secondes
Quelqu'un a t'il déjà observé cela ? y a t-il un contournement ?
Pourquoi ne pas passer par une requête du genre: cReq est une chaine so_MaSource est une source de données
cReq=[ DELETE FROM TEMPO WHERE TEMPO.SESSIONID = %1 ]
cReq=chaineconstruit(creq,idsess) SI pas HExecuteRequeteSQL(so_MaSource,hrequetedefaut,cReq) alors erreur(HErreurInfo()) FIN
-- Pascal
Ne garder que le prénom pour me joindre
Après mure réflexion, patrice a écrit :
Bonjour
Je viens de constater une lenteur assez bizarre lors de la suppression
massive d'enregistrement.
J'utilise des fichiers temporaires , lié à un fichier de session.
(chaque fiche temporaire un un champ SESSIONID qui me permet de tout
supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo durait
30s et la suppression 6minutes!!!)
Apres moult investigations, je m'apercois qu'un truc style :
hlitrecherchepremier(TEMPO,SESSIONID,idsess)
tantque htrouve(TEMPO)
hsupprime(TEMPO)
hlitsuivant(TEMPO)
fin
dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du CPU
Alors que :
pour i=1 A hnbenr(TEMPO)
hlit(TEMPO,i)
si TEMPO.SESSIONID=idess alors
hsupprime(TEMPO)
fin
fin
sur le même fichier avec les mêmes données dure 45 secondes
Quelqu'un a t'il déjà observé cela ?
y a t-il un contournement ?
Pourquoi ne pas passer par une requête du genre:
cReq est une chaine
so_MaSource est une source de données
cReq=[
DELETE FROM TEMPO
WHERE TEMPO.SESSIONID = %1
]
cReq=chaineconstruit(creq,idsess)
SI pas HExecuteRequeteSQL(so_MaSource,hrequetedefaut,cReq) alors
erreur(HErreurInfo())
FIN
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
Je viens de constater une lenteur assez bizarre lors de la suppression massive d'enregistrement. J'utilise des fichiers temporaires , lié à un fichier de session. (chaque fiche temporaire un un champ SESSIONID qui me permet de tout supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo durait 30s et la suppression 6minutes!!!)
Apres moult investigations, je m'apercois qu'un truc style : hlitrecherchepremier(TEMPO,SESSIONID,idsess) tantque htrouve(TEMPO) hsupprime(TEMPO) hlitsuivant(TEMPO) fin dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du CPU
Alors que : pour i=1 A hnbenr(TEMPO) hlit(TEMPO,i) si TEMPO.SESSIONID=idess alors hsupprime(TEMPO) fin fin
sur le même fichier avec les mêmes données dure 45 secondes
Quelqu'un a t'il déjà observé cela ? y a t-il un contournement ?
Pourquoi ne pas passer par une requête du genre: cReq est une chaine so_MaSource est une source de données
cReq=[ DELETE FROM TEMPO WHERE TEMPO.SESSIONID = %1 ]
cReq=chaineconstruit(creq,idsess) SI pas HExecuteRequeteSQL(so_MaSource,hrequetedefaut,cReq) alors erreur(HErreurInfo()) FIN
-- Pascal
Ne garder que le prénom pour me joindre
patrice
"Pascal F" a écrit dans le message de news:441e6a6a$0$12280$
Pourquoi ne pas passer par une requête du genre: cReq est une chaine so_MaSource est une source de données
cReq=[ DELETE FROM TEMPO WHERE TEMPO.SESSIONID = %1 ]
merci pour ta réponse, mais le temps reste comparable (8 sec d'écart entre les 2 méthodes sur 6minutes)
"Pascal F" <N0.pascal.SPAM@efpe.biz> a écrit dans le message de
news:441e6a6a$0$12280$626a54ce@news.free.fr...
Pourquoi ne pas passer par une requête du genre:
cReq est une chaine
so_MaSource est une source de données
cReq=[
DELETE FROM TEMPO
WHERE TEMPO.SESSIONID = %1
]
merci pour ta réponse, mais le temps reste comparable (8 sec d'écart entre
les 2 méthodes sur 6minutes)
"Pascal F" a écrit dans le message de news:441e6a6a$0$12280$
Pourquoi ne pas passer par une requête du genre: cReq est une chaine so_MaSource est une source de données
cReq=[ DELETE FROM TEMPO WHERE TEMPO.SESSIONID = %1 ]
merci pour ta réponse, mais le temps reste comparable (8 sec d'écart entre les 2 méthodes sur 6minutes)
Emmanuel Lecoester
"patrice" a écrit dans le message de news:441e66a6$0$470$
Bonjour
Je viens de constater une lenteur assez bizarre lors de la suppression massive d'enregistrement. J'utilise des fichiers temporaires , lié à un fichier de session. (chaque fiche temporaire un un champ SESSIONID qui me permet de tout supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo
durait
30s et la suppression 6minutes!!!)
Je dirais ...
Apres moult investigations, je m'apercois qu'un truc style : hlitrecherchepremier(TEMPO,SESSIONID,idsess) tantque htrouve(TEMPO) hsupprime(TEMPO) hlitsuivant(TEMPO) fin dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du
CPU
Là vous utilisez l'accès à l'index puis au fichier. A chaque suppression on modifie le fichier sur disque mais aussi l'index ce qui demande une resynchro vu que l'arbre utilisé est reconstruit si il est déséquilibré). La faible utilisation CPU vient du fait du temps passé sur l'accès disque.
Alors que : pour i=1 A hnbenr(TEMPO) hlit(TEMPO,i) si TEMPO.SESSIONID=idess alors hsupprime(TEMPO) fin fin sur le même fichier avec les mêmes données dure 45 secondes
Là vous utilisez directement l'accès au fichier (hlit). Le fichier est modifié et l'index aussi. Sauf que l'index n'est pas parcouru (pas de resynchro nécessaire) et vous accéder en direct sur le fichier (pas de reparcours nécessaire).
Quelqu'un a t'il déjà observé cela ? y a t-il un contournement ?
Techniques pour les sgbd : Avoir moins d'indexes, désactiver les indexes - faire les suppression - rebuild des indexes
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news:441e66a6$0$470$626a54ce@news.free.fr...
Bonjour
Je viens de constater une lenteur assez bizarre lors de la suppression
massive d'enregistrement.
J'utilise des fichiers temporaires , lié à un fichier de session.
(chaque fiche temporaire un un champ SESSIONID qui me permet de tout
supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo
durait
30s et la suppression 6minutes!!!)
Je dirais ...
Apres moult investigations, je m'apercois qu'un truc style :
hlitrecherchepremier(TEMPO,SESSIONID,idsess)
tantque htrouve(TEMPO)
hsupprime(TEMPO)
hlitsuivant(TEMPO)
fin
dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du
CPU
Là vous utilisez l'accès à l'index puis au fichier. A chaque suppression on
modifie le fichier sur disque mais aussi l'index ce qui demande une
resynchro vu que l'arbre utilisé est reconstruit si il est déséquilibré). La
faible utilisation CPU vient du fait du temps passé sur l'accès disque.
Alors que :
pour i=1 A hnbenr(TEMPO)
hlit(TEMPO,i)
si TEMPO.SESSIONID=idess alors
hsupprime(TEMPO)
fin
fin
sur le même fichier avec les mêmes données dure 45 secondes
Là vous utilisez directement l'accès au fichier (hlit). Le fichier est
modifié et l'index aussi. Sauf que l'index n'est pas parcouru (pas de
resynchro nécessaire) et vous accéder en direct sur le fichier (pas de
reparcours nécessaire).
Quelqu'un a t'il déjà observé cela ?
y a t-il un contournement ?
Techniques pour les sgbd : Avoir moins d'indexes, désactiver les indexes -
faire les suppression - rebuild des indexes
"patrice" a écrit dans le message de news:441e66a6$0$470$
Bonjour
Je viens de constater une lenteur assez bizarre lors de la suppression massive d'enregistrement. J'utilise des fichiers temporaires , lié à un fichier de session. (chaque fiche temporaire un un champ SESSIONID qui me permet de tout supprimer quand j'en ai plus besoin)
Je me suis apercu de lenteur anormale dans le DeleteSessionID (l'algo
durait
30s et la suppression 6minutes!!!)
Je dirais ...
Apres moult investigations, je m'apercois qu'un truc style : hlitrecherchepremier(TEMPO,SESSIONID,idsess) tantque htrouve(TEMPO) hsupprime(TEMPO) hlitsuivant(TEMPO) fin dure environ 6 minute pour 40000 enregistrement, et n'utilise que 5% du
CPU
Là vous utilisez l'accès à l'index puis au fichier. A chaque suppression on modifie le fichier sur disque mais aussi l'index ce qui demande une resynchro vu que l'arbre utilisé est reconstruit si il est déséquilibré). La faible utilisation CPU vient du fait du temps passé sur l'accès disque.
Alors que : pour i=1 A hnbenr(TEMPO) hlit(TEMPO,i) si TEMPO.SESSIONID=idess alors hsupprime(TEMPO) fin fin sur le même fichier avec les mêmes données dure 45 secondes
Là vous utilisez directement l'accès au fichier (hlit). Le fichier est modifié et l'index aussi. Sauf que l'index n'est pas parcouru (pas de resynchro nécessaire) et vous accéder en direct sur le fichier (pas de reparcours nécessaire).
Quelqu'un a t'il déjà observé cela ? y a t-il un contournement ?
Techniques pour les sgbd : Avoir moins d'indexes, désactiver les indexes - faire les suppression - rebuild des indexes
