|
| HéxecuteRequete => renvoi erreur timeOut |
| Iniciado por g.L, abr., 02 2024 3:41 PM - 7 respostas |
| |
| | | |
|
| |
Membro registado
120 mensagems |
|
Publicado em abril, 02 2024 - 3:41 PM |
Bonjour a tous question simple mais qui me prend la tête ^^
J'aimerai savoir si il y a un moyen de rallonger le temps d'attente d'une réponse suite a l'exécution d'une requête
avec HéxecuteRequete ??
J'ai un problème je doit afficher l'historique des mouvement d'un stock mais voila sur un ou deux article (les plus vendu)
j'ai un timeout la requête a mis plus de 90 sec a répondre
et du coup ça coupe tout ...
comment je peux bouger cela ou augmenter le temps d'attente a je sais pas disons 3 minute ou 5 minute |
| |
| |
| | | |
|
| | |
| |
Membro registado
951 mensagems
Popularité : +53 (63 votes) |
|
Publicado em abril, 02 2024 - 4:16 PM |
| |
| |
| | | |
|
| | |
| |
Membro registado
120 mensagems |
|
Publicado em abril, 03 2024 - 11:47 AM |
ok bon je pense que modifier le temps de réponse n'est pas une bonne solution (peut engendré beaucoup de problème, et je vois mal le client attendre 3 minute ou 5 minute que la page s'affiche )
Ni a til pas un moyen de faire un Hexecuterequete et de gérer le timeOut ? genre en l'empêchant de fermer l'application mais juste en affichant un message d'erreur ou autre ?
la je comprend pas pour la même requête avec les même critère de sélection et le même nombre de ligne a renvoyer parfois ça prend 11s parfois 8s et parfois 7 minute ? je sais pas pourquoi
ou comment je peux optimiser cette requête ?
SELECT
StockArticleMouvements.IDStockArticleMouvements AS IDStockArticleMouvements,
StockArticleMouvements.DATEMOUVEMENT AS DATEMOUVEMENT,
StockArticleMouvements.QUANTITE AS QUANTITE,
StockArticleMouvements.DATECREATION AS DATECREATION,
StockArticleMouvements.IDUTILISATEURCREATION AS IDUTILISATEURCREATION,
StockArticleMouvements.DLUO AS DLUO,
StockArticleMouvements.NUMLOT AS NUMLOT,
StockArticleMouvements.IDRefTypeMouvementStock AS IDRefTypeMouvementStock,
StockArticleMouvements.PRIX_ACHAT_HT AS PRIX_ACHAT_HT,
StockArticle.IDRefPrestataire AS IDRefPrestataire,
StockArticle.IDARTICLE AS IDARTICLE,
RefTypeMouvementStock.LibTypeMouvementStock AS LibTypeMouvementStock,
RefPrestataire.LIBPRESTATAIRE AS LIBPRESTATAIRE,
ARTICLE.LIB_ARTICLE AS LIB_ARTICLE
FROM
RefTypeMouvementStock,
StockArticleMouvements,
StockArticle,
RefPrestataire,
ARTICLE
WHERE
(
StockArticle.IDARTICLE = 100001
AND StockArticleMouvements.DATEMOUVEMENT BETWEEN 20220101 AND 20240403
)
AND ARTICLE.IDARTICLE = StockArticle.IDARTICLE
AND RefPrestataire.IDRefPrestataire = StockArticle.IDRefPrestataire
AND RefTypeMouvementStock.IDRefTypeMouvementStock = StockArticleMouvements.IDRefTypeMouvementStock
AND StockArticleMouvements.IDStockArticle = StockArticle.IDStockArticle |
| |
| |
| | | |
|
| | |
| |
Publicado em abril, 03 2024 - 12:05 PM |
Après mûre réflexion, g.L a écrit :
ok bon je pense que modifier le temps de réponse n'est pas une bonne solution
(peut engendré beaucoup de problème, et je vois mal le client attendre 3
minute ou 5 minute que la page s'affiche )
Ni a til pas un moyen de faire un Hexecuterequete et de gérer le timeOut ?
genre en l'empêchant de fermer l'application mais juste en affichant un
message d'erreur ou autre ? la je comprend pas pour la même requête avec les
même critère de sélection et le même nombre de ligne a renvoyer parfois ça
prend 11s parfois 8s et parfois 7 minute ? je sais pas pourquoi
ou comment je peux optimiser cette requête ?
SELECT StockArticleMouvements.IDStockArticleMouvements AS
IDStockArticleMouvements,
StockArticleMouvements.DATEMOUVEMENT AS DATEMOUVEMENT,
StockArticleMouvements.QUANTITE AS QUANTITE,
StockArticleMouvements.DATECREATION AS DATECREATION,
StockArticleMouvements.IDUTILISATEURCREATION AS IDUTILISATEURCREATION,
StockArticleMouvements.DLUO AS DLUO,
StockArticleMouvements.NUMLOT AS NUMLOT,
StockArticleMouvements.IDRefTypeMouvementStock AS IDRefTypeMouvementStock,
StockArticleMouvements.PRIX_ACHAT_HT AS PRIX_ACHAT_HT,
StockArticle.IDRefPrestataire AS IDRefPrestataire,
StockArticle.IDARTICLE AS IDARTICLE,
RefTypeMouvementStock.LibTypeMouvementStock AS LibTypeMouvementStock,
RefPrestataire.LIBPRESTATAIRE AS LIBPRESTATAIRE,
ARTICLE.LIB_ARTICLE AS LIB_ARTICLE
FROM RefTypeMouvementStock,
StockArticleMouvements,
StockArticle,
RefPrestataire,
ARTICLE
WHERE (
StockArticle.IDARTICLE = 100001
AND StockArticleMouvements.DATEMOUVEMENT BETWEEN 20220101 AND 20240403
)
AND ARTICLE.IDARTICLE = StockArticle.IDARTICLE
AND RefPrestataire.IDRefPrestataire = StockArticle.IDRefPrestataire
AND RefTypeMouvementStock.IDRefTypeMouvementStock =
StockArticleMouvements.IDRefTypeMouvementStock
AND StockArticleMouvements.IDStockArticle = StockArticle.IDStockArticle
Eternel problème
j'aurais voulu (demande faite il y a plusieurs versions ) que l'on
puisse augmenter ce temps par programation et seulement pour la session
courante; mais cela n'a jamais été pris en compte.
confronté souvent à ce type de traitement (notamment des extractions
excel de plus de 100000 lignes), il y a bien sûr l'indispensable popup
pour patienter (relativement compliquée d'ailleurs à mettre en oeuvre à
chaque fois) mais cela ne résoud pas le pb des times out.
Donc je fais souvent une soumission de la requete que je stocke en base
sous forme de todo. Un projet webdev de taches schedullées passe toutes
les x minutes, heures ou le soir si c'est trop lourd et traîte ces
batchs (là le projet donne des times out larges) et envoie un mail
d'accomplissement à la personne.
C'est lourd à mettre au point mais c'est bien accepté et compris par
les utilisateurs.
--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com |
| |
| |
| | | |
|
| | |
| |
Membro registado
120 mensagems |
|
Publicado em abril, 03 2024 - 3:42 PM |
| |
| |
| | | |
|
| | |
| |
Membro registado
398 mensagems
Popularité : +13 (13 votes) |
|
Publicado em abril, 03 2024 - 5:01 PM |
Bonjour,
Première remarque : essayez de passer par des vraies jointures :
SELECT
mouv.IDStockArticleMouvements AS IDStockArticleMouvements,
type.LibTypeMouvementStock AS LibTypeMouvementStock,
presta.LIBPRESTATAIRE AS LIBPRESTATAIRE,
ARTICLE.LIB_ARTICLE AS LIB_ARTICLE
FROM
ARTICLE
INNER JOIN StockArticle stock
ON ARTICLE.IDARTICLE = stock.IDARTICLE
INNER JOIN StockArticleMouvements mouv
ON mouv.IDStockArticle = stock.IDStockArticle
ON mouv.DATEMOUVEMENT BETWEEN '20220101' AND '20240403'
INNER JOIN RefTypeMouvementStock type
ON type.IDRefTypeMouvementStock = mouv.IDRefTypeMouvementStock
INNER JOIN RefPrestataire presta
ON presta.IDRefPrestataire = stock.IDRefPrestataire
WHERE
ARTICLE.IDARTICLE = 100001
Deuxième remarque, vérifiez que les colonnes suivantes soient bien en clés avec doublons, avec les relations qu'il faut :
- StockArticle.IDARTICLE
- StockArticle.IDRefPrestataire
- StockArticleMouvements.IDStockArticle
- StockArticleMouvements.DATEMOUVEMENT
- StockArticleMouvements.IDRefTypeMouvementStock
Toisième remarque : si c'est "normal" qu'elle rappatrie 125k lignes, ça fait tout de même un paquet de lignes à traiter / à stocker en mémoire vive / à parcourir :
- se poser la question de ce qu'on fait exactement de toute ces lignes : ça parait inimaginable que l'utilisateur ait réellement besoin d'accéder à chacune de ses 125k lignes sur un affichage
- peut-être rendre la requête plus discriminante en forçant des filtres
- éventuellement voir du côté des fonctions d'agrégation si ce n'est qu'une synthèse qui intéresse.
Quatrième et dernière remarque : si vous êtes en WebDev, la génération du HTML nécessaire peut jouer notamment dans le timeout, notamment :
- si les résultats sont affichés dans une ZR (qui voudra lister 125k lignes)
- ou dans un champ table non AJAX (où les 125k lignes seront générées également)
On peut peut-être vous aider plus que ça, mais il va falloir nous en dire plus : usage prévu, volumétrie de la base et de la requête, etc... |
| |
| |
| | | |
|
| | |
| |
Membro registado
120 mensagems |
|
Publicado em abril, 04 2024 - 9:47 AM |
merci pour ta réponse je vais tester avec de vrai jointure mais ça c'est les collègue qui préférer l'autre jointure
pour répondre a ta deuxième remarque oui elle sont toute clé secondaire
troisième remarque : c'est tout simplement ce que le client veut .. on as beau dire c'est trop il le veut
quatrième remarque c'est afficher dans un champ table ajax ^^
comme je l'ai dit le fichier dans lequel la requête recherche comporte 3million d'enregistrement et l'utilisateur veut afficher la liste de tout les mouvements de stock des 2 dernières années,
ou de date qu'il choisi avec un article choisie ou toute article confondu (je sais c'est pas forcement une bonne idée )
moi le truc que je trouve inquiétant c'est que une fois la requête dans le centre de contrôle HFSQL et non sur le site
met 11 minute et les fois d'après 8 seconde ????
pourquoi ?
bref je vais voir pour rendre la requête plus discriminante |
| |
| |
| | | |
|
| | |
| |
Membro registado
120 mensagems |
|
Publicado em abril, 04 2024 - 11:43 AM |
j'ai tester avec de "Vrai jointure" et le temps d'éxécution est le meme je vais voir avec le client et mon manageur pour contraindre la recherche par mois ou sur 6 mois avec obligatoirement un article |
| |
| |
| | | |
|
| | | | |
| | |
|