Traitement LDAP trop long!

Version imprimable

Bonjour,

Je souhaite récupérer à l'aide d'un web service le nom et prénom de tous les utilisateurs de mon AD qui correspondent à une OU spécifique et qui on un email et un employeeID.

Voici le code que j'utilise :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[WebMethod]
        public ADUser[] GetUser()
        {
            List<ADUser> adUserList = new List<ADUser>();
            try
            {
                DirectoryEntry ldap = new DirectoryEntry(ConfigurationSettings.AppSettings["LdapUrl"], ConfigurationSettings.AppSettings["LdapLogin"], ConfigurationSettings.AppSettings["LdapPwd"]);
                DirectorySearcher searcher = new DirectorySearcher(ldap);
                searcher.Filter = "(&(objectClass=user)(mail=*)(employeeID=*))";
                SearchResultCollection AdUsers = searcher.FindAll();
                foreach (SearchResult result in AdUsers)
                {
                    DirectoryEntry DirEntry = result.GetDirectoryEntry();
                    ADUser user = new ADUser(DirEntry.Properties["cn"].Value.ToString());
                    adUserList.Add(user);
                }
                adUserList.Sort();
            }
            catch (Exception ex)
            {
                adUserList.Add(new ADUser(ex.Message));
            }
            return adUserList.ToArray();
        }

Voici mon LDAP URL dans le web.config :

Citation:

Ce code fonctionne parfaitement, pas le moindre problème :ccool:, en revanche, il met environ 15 secondes avant de me donner un résultat.:aie:
Je souhaites donc savoir s'il est possible d'améliorer mon traitement pour que celui-ci soit plus rapide.

Je suis preneur de toute optimisation.
Merci par avance.

21/04/2011, 15h00
Er3van

Si le temps de 15s est consommé à 99% au niveau de

Code:

SearchResultCollection AdUsers = searcher.FindAll()

je ne vois pas trop ce qui peut-être fait, excepté optimisé la requête... mais en LDAP ce n'est pas vraiment facile à faire à ma connaissance !
21/04/2011, 16h14
Max

Salut.

Peux-tu effectuer le test suivant : dans un browser LDAP (Softerra, Apache Directory Studio, etc.), positionne toi sur ton OU et fait une recherche avec le même filtre. Obtiens-tu une différence de performance ?

Parce que là, comme Er3van, ton code il me semble correct. Après peut-être voir du côté du paramétrage de ton AD.
21/04/2011, 16h31
ludojojo

J'en suis arrivé à la même conclusion...
Mais est ce que si je passe par une autre méthode de tri que celle par défault, n'est il pas possible de gagner du temps?
22/04/2011, 09h07
Max

Et en terme de volumétrie, ta requête est censée te renvoyer combien de users ?
22/04/2011, 09h39
WOLO Laurent
Les perf sont généralement liées à beaucoup de paramètres :
1. La ram de ton poste client
2. La fréquence de processeur du client
3. L'espace disque système
4. La vitesse de ta carte réseau
5. La vitesse de ton réseau
6. La capacité du disque du serveur LDAP
7. La capacité de la ram sur le serveur LDAP
Il faut commencer par trouver le goulot d'étranglement.
22/04/2011, 09h41
Er3van

Une simple remarque :

(&(objectClass=user)(mail=*)(employeeID=*))

On est d'accord que tu veux tous les users ayant un employeeID et une adresse mail (sous entendu non nuls).

Est-ce que tu ne pourrais pas affiner ta recherche en partant d'une racine spécifique ? J'imagine qu'une des branches doit contenir des comptes/groupes et donc pas d'user.

Pas sûr qu'il y ait un gain si tu dois chercher dans "toutes les branches sauf une" ceci dit...
22/04/2011, 11h22
ludojojo
Citation:

Envoyé par _Max_

Salut.

Peux-tu effectuer le test suivant : dans un browser LDAP (Softerra, Apache Directory Studio, etc.), positionne toi sur ton OU et fait une recherche avec le même filtre. Obtiens-tu une différence de performance ?

Non malheureusement pas d'amélioration de ce coté là...

Citation:

Envoyé par _Max_

Et en terme de volumétrie, ta requête est censée te renvoyer combien de users ?

Entre 600 et 800 users, pour le moment.
Citation:
Envoyé par WOLO Laurent

Les perf sont généralement liées à beaucoup de paramètres :

La ram de ton poste client
La fréquence de processeur du client
...

Il faut commencer par trouver le goulot d'étranglement.
Malheureusement, je n'ai pas de moyen de maitriser cela. Le webService doit pouvoir être appelé depuis n'importe quel pc du réseau, avec des configurations assez différentes et pas des machines de guerre. Il me semblais que le webservice s'exécutait uniquement sur le serveur et que le client ne faisait que le consommer... non?

Citation:

Envoyé par Er3van

Une simple remarque :

(&(objectClass=user)(mail=*)(employeeID=*))

On est d'accord que tu veux tous les users ayant un employeeID et une adresse mail (sous entendu non nuls).

Tout à fait !

Citation:

Envoyé par Er3van

Est-ce que tu ne pourrais pas affiner ta recherche en partant d'une racine spécifique ? J'imagine qu'une des branches doit contenir des comptes/groupes et donc pas d'user.

Bien vu, je vais essayer de réduire encore au maximum le champs de recherche, je vous dirait ce qu'il en ressort.
22/04/2011, 11h34
ludojojo
Citation:

Envoyé par Er3van

Est-ce que tu ne pourrais pas affiner ta recherche en partant d'une racine spécifique ? J'imagine qu'une des branches doit contenir des comptes/groupes et donc pas d'user.

Dans cette direction, est ce que dans mon filter je ne pourais pas spécifier directement les groupe que je souhaite ne pas interroger? J'entends par là des sous groupes du groupe racine de ma recherche.

Pas sur d'être bien clair, alors voici un exemple :
- 1
- 2(Racine de ma recherche)
  - 1(celui que je ne veux pas interroger...)
  - 2(un de ceux que je veux interroger...)
  - 3(un de ceux que je veux interroger...)
  Si cela n'alourdit pas le traitement bien sur...
29/04/2011, 09h43
ludojojo

Re-bonjour !

Je reviens ajouter une information car cela pour servir à quelqu'un...
En fait pour améliorer la rapidité d'exécution de la requête, il faut non pas réduire le champs de recherche, mais réduire la quantité d'informations à récupérer. Pour cela il suffit de rajouter une ligne...

Voici le code :

Code:

search.PropertiesToLoad.Add("cn");

Temps d'exécution divisé par 4 au moins!
Voilà, en espérant que cela serve à quelqu'un.

Merci pour votre aide.:mouarf:
04/05/2011, 13h24
Er3van

En effet, mais à condition de n'avoir besoin que du CN de l'user en question.

Ceci, c'est plus rapide de récupérer tous les CN et de récupérer les autres informations à la demande...

Après réflexion, il me semble qu'il y a bien une erreur dans ton code. Car la ligne que tu as ajoutée doit modifier les performances, mais il y a encore moyen de l'améliorer. Parce que ton appel vers GetDirectoryEntry recharge toute l'entrée AD. Je m'explique :

search.PropertiesToLoad.Add("cn"); effectivement sur ton FindAll, seul cet attribut va être chargé (plus l'adspath) ;
mais après quand tu fais GetDirectoryEntry ça refait un appel AD et charge tous les attributs de l'entrée (peu importe ce que tu as filtré avant).

Pourrais-tu donc faire le test suivant stp et nous donner les résultats de ce que tu peux voir au débuggeur (notamment sur ton DirectoryEntry pour vérifier que tu as bien tout chargé) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 foreach (SearchResult result in AdUsers) { // Ici ton result ne contient effectivement que les attributs que tu as demandé, tu peux d'ailleurs le tester : Console.WriteLine("Properties loaded in the SearchResult: {0}", result.Properties.Count); foreach (string currentName in result.Properties.PropertyNames) { Console.WriteLine("Property name = {0}", currentName); Console.WriteLine("Property values:"); foreach (string currentValue in result.Properties[currentName]) { Console.WriteLine("Value = {0}", currentValue); } } // Avec GetDirectoryEntry, tu refais un appel vers l'AD et tu charges tous les attributs de l'entrée en question DirectoryEntry DirEntry = result.GetDirectoryEntry(); Console.WriteLine("Properties loaded with GetDirectoryEntry: {0}", DirEntry.Properties.Count); ADUser user = new ADUser(DirEntry.Properties["cn"].Value.ToString()); adUserList.Add(user); }

05/05/2011, 10h29
ludojojo
Citation:
Envoyé par _Max_

Après réflexion, il me semble qu'il y a bien une erreur dans ton code. Car la ligne que tu as ajoutée doit modifier les performances, mais il y a encore moyen de l'améliorer. Parce que ton appel vers GetDirectoryEntry recharge toute l'entrée AD. Je m'explique :

search.PropertiesToLoad.Add("cn"); effectivement sur ton FindAll, seul cet attribut va être chargé (plus l'adspath) ;
mais après quand tu fais GetDirectoryEntry ça refait un appel AD et charge tous les attributs de l'entrée (peu importe ce que tu as filtré avant).
Alors là, Bravo ! :hola:
C'est casiment instantané ! En effet, sans l'utilisation de DirectoryEntry dans la boucle (ce qui explique cette longeur dans l'exécution) le script est extrêment rapide.
Merci beaucoup pour cette aide !