ASP.NET - asynchrone - parallèle

Le
Gilbert Tordeur
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrice
Le #21471731
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" 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
Le #21473461
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"
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" 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





Publicité
Poster une réponse
Anonyme