|
FORUMS PROFESSIONNELS WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
HéxecuteRequete => renvoi erreur timeOut |
Débuté par g.L, 02 avr. 2024 15:41 - 7 réponses |
| |
| | | |
|
| |
Membre enregistré 120 messages |
|
Posté le 02 avril 2024 - 15:41 |
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 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 961 messages Popularité : +53 (63 votes) |
|
Posté le 02 avril 2024 - 16:16 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 120 messages |
|
Posté le 03 avril 2024 - 11:47 |
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 |
| |
| |
| | | |
|
| | |
| |
Posté le 03 avril 2024 - 12:05 |
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 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 120 messages |
|
Posté le 03 avril 2024 - 15:42 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 428 messages Popularité : +13 (13 votes) |
|
Posté le 03 avril 2024 - 17:01 |
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... |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 120 messages |
|
Posté le 04 avril 2024 - 09:47 |
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 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré 120 messages |
|
Posté le 04 avril 2024 - 11:43 |
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 |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|