J'ai une application intranet écrite en VB2008 dont une page met
actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des
informations dans l'Active Directory pour tous ses utilisateurs autorisés
(groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer
l'application, c'est supportable. Mais :
1. elle bloque un thread beaucoup trop longtemps ;
2. comme son temps de réponse est proportionnel au nombre d'utilisateurs
autorisés, et que celui ne fera que croître, il est certain que la situation
va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je n'ai
rien trouvé en ce sens.
2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans
consommer plus de thread du pool ?
3. Le déport de cette fonctionalité dans un web service (sur le même serveur
IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt.
3. VB2010 apportera-t-il un élément de solution par le support de processus
parallèles ?
4. Quel conseil général pourriez-vous me donner ?
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
Patrice
Bonjour,
Peut-être avec une "page asynchrone" ? http://msdn.microsoft.com/en-us/magazine/cc163725.aspx#S2
Avant, je commencerais tout de même par vérifier le code d'origine pour notamment être sûr de bien identifier ce qui est lent (par exemple, si tous les utilisateur sont affichés cela pourrait être la génération d'une page HTML très volumineuse, plutôt que l'interrogation AD elle-même qui causerait le problème)
Je ne suis pas très familier d'AD mais je crois avoir vu une fois que selon la façon dont la requête AD est formulée, elle peut récupérer tous les objets et tester le type où récupérer directement les utilisateurs etc...
-- Patrice
"Gilbert Tordeur" a écrit dans le message de groupe de discussion :
Bonjour.
J'ai une application intranet écrite en VB2008 dont une page met actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des informations dans l'Active Directory pour tous ses utilisateurs autorisés (groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer l'application, c'est supportable. Mais : 1. elle bloque un thread beaucoup trop longtemps ; 2. comme son temps de réponse est proportionnel au nombre d'utilisateurs autorisés, et que celui ne fera que croître, il est certain que la situation va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je n'ai rien trouvé en ce sens. 2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans consommer plus de thread du pool ? 3. Le déport de cette fonctionalité dans un web service (sur le même serveur IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt. 3. VB2010 apportera-t-il un élément de solution par le support de processus parallèles ? 4. Quel conseil général pourriez-vous me donner ?
Merci d'avance, Gilbert
Bonjour,
Peut-être avec une "page asynchrone" ?
http://msdn.microsoft.com/en-us/magazine/cc163725.aspx#S2
Avant, je commencerais tout de même par vérifier le code d'origine pour
notamment être sûr de bien identifier ce qui est lent (par exemple, si tous
les utilisateur sont affichés cela pourrait être la génération d'une page
HTML très volumineuse, plutôt que l'interrogation AD elle-même qui causerait
le problème)
Je ne suis pas très familier d'AD mais je crois avoir vu une fois que selon
la façon dont la requête AD est formulée, elle peut récupérer tous les
objets et tester le type où récupérer directement les utilisateurs etc...
--
Patrice
"Gilbert Tordeur" <gilbert.tordeur@orange.fr> a écrit dans le message de
groupe de discussion : uZqv8IK0KHA.4832@TK2MSFTNGP04.phx.gbl...
Bonjour.
J'ai une application intranet écrite en VB2008 dont une page met
actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des
informations dans l'Active Directory pour tous ses utilisateurs autorisés
(groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer
l'application, c'est supportable. Mais :
1. elle bloque un thread beaucoup trop longtemps ;
2. comme son temps de réponse est proportionnel au nombre d'utilisateurs
autorisés, et que celui ne fera que croître, il est certain que la
situation va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je n'ai
rien trouvé en ce sens.
2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans
consommer plus de thread du pool ?
3. Le déport de cette fonctionalité dans un web service (sur le même
serveur IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt.
3. VB2010 apportera-t-il un élément de solution par le support de
processus parallèles ?
4. Quel conseil général pourriez-vous me donner ?
Peut-être avec une "page asynchrone" ? http://msdn.microsoft.com/en-us/magazine/cc163725.aspx#S2
Avant, je commencerais tout de même par vérifier le code d'origine pour notamment être sûr de bien identifier ce qui est lent (par exemple, si tous les utilisateur sont affichés cela pourrait être la génération d'une page HTML très volumineuse, plutôt que l'interrogation AD elle-même qui causerait le problème)
Je ne suis pas très familier d'AD mais je crois avoir vu une fois que selon la façon dont la requête AD est formulée, elle peut récupérer tous les objets et tester le type où récupérer directement les utilisateurs etc...
-- Patrice
"Gilbert Tordeur" a écrit dans le message de groupe de discussion :
Bonjour.
J'ai une application intranet écrite en VB2008 dont une page met actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des informations dans l'Active Directory pour tous ses utilisateurs autorisés (groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer l'application, c'est supportable. Mais : 1. elle bloque un thread beaucoup trop longtemps ; 2. comme son temps de réponse est proportionnel au nombre d'utilisateurs autorisés, et que celui ne fera que croître, il est certain que la situation va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je n'ai rien trouvé en ce sens. 2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans consommer plus de thread du pool ? 3. Le déport de cette fonctionalité dans un web service (sur le même serveur IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt. 3. VB2010 apportera-t-il un élément de solution par le support de processus parallèles ? 4. Quel conseil général pourriez-vous me donner ?
Merci d'avance, Gilbert
Gilbert Tordeur
Bonjour Patrice, et merci pour ta réponse.
J'ai bien identifié où la page était lente, par des Trace.Warn. C'est dans une boucle où je cherche des informations AD pour quelques centaines d'utilisateurs, plus des accès SQL.
J'avais déjà lu hier l'article que tu me présentes, et d'autres. Mais tous les exemples d'asynchrone en ASP utilisent soit une lecture SQL avec BeginExecuteReader, soit un accès Web avec BeginGetResponse. Or moi je ne suis pas vraiment dans ce cas de figure, je lis des enregistrements AD, et à ma connaissance AD ne propose pas d'accès asynchrone. Il me faudrait donc envelopper l'accès AD par une couche asynchrone, en ASP.NET, et je ne sais pas comment, ni même si c'est possible, et s'il est possible d'en exécuter plusieurs à la fois (parce que si le système les exécute en séquence, je ne gagne pas beaucoup de temps...).
Je fais bien un seul accès à l'AD par utilisateur, pour récupérer toutes ses informations. Est-il possible de lire en un seul accès les informations de plusieurs utilisateurs ?
Bonne soirée, Gilbert
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
Bonjour,
Peut-être avec une "page asynchrone" ? http://msdn.microsoft.com/en-us/magazine/cc163725.aspx#S2
Avant, je commencerais tout de même par vérifier le code d'origine pour notamment être sûr de bien identifier ce qui est lent (par exemple, si tous les utilisateur sont affichés cela pourrait être la génération d'une page HTML très volumineuse, plutôt que l'interrogation AD elle-même qui causerait le problème)
Je ne suis pas très familier d'AD mais je crois avoir vu une fois que selon la façon dont la requête AD est formulée, elle peut récupérer tous les objets et tester le type où récupérer directement les utilisateurs etc...
-- Patrice
"Gilbert Tordeur" a écrit dans le message de groupe de discussion :
Bonjour.
J'ai une application intranet écrite en VB2008 dont une page met actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des informations dans l'Active Directory pour tous ses utilisateurs autorisés (groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer l'application, c'est supportable. Mais : 1. elle bloque un thread beaucoup trop longtemps ; 2. comme son temps de réponse est proportionnel au nombre d'utilisateurs autorisés, et que celui ne fera que croître, il est certain que la situation va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je n'ai rien trouvé en ce sens. 2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans consommer plus de thread du pool ? 3. Le déport de cette fonctionalité dans un web service (sur le même serveur IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt. 3. VB2010 apportera-t-il un élément de solution par le support de processus parallèles ? 4. Quel conseil général pourriez-vous me donner ?
Merci d'avance, Gilbert
Bonjour Patrice, et merci pour ta réponse.
J'ai bien identifié où la page était lente, par des Trace.Warn. C'est dans
une boucle où je cherche des informations AD pour quelques centaines
d'utilisateurs, plus des accès SQL.
J'avais déjà lu hier l'article que tu me présentes, et d'autres. Mais tous
les exemples d'asynchrone en ASP utilisent soit une lecture SQL avec
BeginExecuteReader, soit un accès Web avec BeginGetResponse. Or moi je ne
suis pas vraiment dans ce cas de figure, je lis des enregistrements AD, et à
ma connaissance AD ne propose pas d'accès asynchrone. Il me faudrait donc
envelopper l'accès AD par une couche asynchrone, en ASP.NET, et je ne sais
pas comment, ni même si c'est possible, et s'il est possible d'en exécuter
plusieurs à la fois (parce que si le système les exécute en séquence, je ne
gagne pas beaucoup de temps...).
Je fais bien un seul accès à l'AD par utilisateur, pour récupérer toutes ses
informations. Est-il possible de lire en un seul accès les informations de
plusieurs utilisateurs ?
Bonne soirée,
Gilbert
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
uWkvYkM0KHA.220@TK2MSFTNGP06.phx.gbl...
Bonjour,
Peut-être avec une "page asynchrone" ?
http://msdn.microsoft.com/en-us/magazine/cc163725.aspx#S2
Avant, je commencerais tout de même par vérifier le code d'origine pour
notamment être sûr de bien identifier ce qui est lent (par exemple, si
tous les utilisateur sont affichés cela pourrait être la génération d'une
page HTML très volumineuse, plutôt que l'interrogation AD elle-même qui
causerait le problème)
Je ne suis pas très familier d'AD mais je crois avoir vu une fois que
selon la façon dont la requête AD est formulée, elle peut récupérer tous
les objets et tester le type où récupérer directement les utilisateurs
etc...
--
Patrice
"Gilbert Tordeur" <gilbert.tordeur@orange.fr> a écrit dans le message de
groupe de discussion : uZqv8IK0KHA.4832@TK2MSFTNGP04.phx.gbl...
Bonjour.
J'ai une application intranet écrite en VB2008 dont une page met
actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des
informations dans l'Active Directory pour tous ses utilisateurs autorisés
(groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer
l'application, c'est supportable. Mais :
1. elle bloque un thread beaucoup trop longtemps ;
2. comme son temps de réponse est proportionnel au nombre
d'utilisateurs autorisés, et que celui ne fera que croître, il est
certain que la situation va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je
n'ai rien trouvé en ce sens.
2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans
consommer plus de thread du pool ?
3. Le déport de cette fonctionalité dans un web service (sur le même
serveur IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt.
3. VB2010 apportera-t-il un élément de solution par le support de
processus parallèles ?
4. Quel conseil général pourriez-vous me donner ?
J'ai bien identifié où la page était lente, par des Trace.Warn. C'est dans une boucle où je cherche des informations AD pour quelques centaines d'utilisateurs, plus des accès SQL.
J'avais déjà lu hier l'article que tu me présentes, et d'autres. Mais tous les exemples d'asynchrone en ASP utilisent soit une lecture SQL avec BeginExecuteReader, soit un accès Web avec BeginGetResponse. Or moi je ne suis pas vraiment dans ce cas de figure, je lis des enregistrements AD, et à ma connaissance AD ne propose pas d'accès asynchrone. Il me faudrait donc envelopper l'accès AD par une couche asynchrone, en ASP.NET, et je ne sais pas comment, ni même si c'est possible, et s'il est possible d'en exécuter plusieurs à la fois (parce que si le système les exécute en séquence, je ne gagne pas beaucoup de temps...).
Je fais bien un seul accès à l'AD par utilisateur, pour récupérer toutes ses informations. Est-il possible de lire en un seul accès les informations de plusieurs utilisateurs ?
Bonne soirée, Gilbert
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
Bonjour,
Peut-être avec une "page asynchrone" ? http://msdn.microsoft.com/en-us/magazine/cc163725.aspx#S2
Avant, je commencerais tout de même par vérifier le code d'origine pour notamment être sûr de bien identifier ce qui est lent (par exemple, si tous les utilisateur sont affichés cela pourrait être la génération d'une page HTML très volumineuse, plutôt que l'interrogation AD elle-même qui causerait le problème)
Je ne suis pas très familier d'AD mais je crois avoir vu une fois que selon la façon dont la requête AD est formulée, elle peut récupérer tous les objets et tester le type où récupérer directement les utilisateurs etc...
-- Patrice
"Gilbert Tordeur" a écrit dans le message de groupe de discussion :
Bonjour.
J'ai une application intranet écrite en VB2008 dont une page met actuellement 3 à 5 minutes pour s'afficher. En effet, elle recherche des informations dans l'Active Directory pour tous ses utilisateurs autorisés (groupes et userids), et c'est lent.
Comme cette page est très peu utilisée, uniquement pour administrer l'application, c'est supportable. Mais : 1. elle bloque un thread beaucoup trop longtemps ; 2. comme son temps de réponse est proportionnel au nombre d'utilisateurs autorisés, et que celui ne fera que croître, il est certain que la situation va empirer.
Comment remédier à cette situation ?
1. Est-il possible de lancer des lectures sur l'AD en asynchrone ? Je n'ai rien trouvé en ce sens. 2. Est-il possible de lancer des lectures sur l'AD en parallèle ? Sans consommer plus de thread du pool ? 3. Le déport de cette fonctionalité dans un web service (sur le même serveur IIS) changerait-il quelque chose ? Moi je ne vois pas l'intérêt. 3. VB2010 apportera-t-il un élément de solution par le support de processus parallèles ? 4. Quel conseil général pourriez-vous me donner ?
