Univention Bugzilla – Bug 22879
5000 Benutzer
Last modified: 2011-12-13 15:49:13 CET
In UCS 3.0 sollen 5000 Benutzer out of the box unterstützt werden.
Performance-Messung UMC/UDM mit 5000 Benutzern: - UCS 3.0 (mit UDM Performance-Verbesserungen), 1GB RAM, 1 CPU - UCS 2.4-2, 1GB RAM, 1 CPU, directory/manager/web/ldap/sizelimit=6000 Auf beiden Systemen ist die automatische Suche an. Ich habe dann jeweils auf den Benutzer-Assistenten geklickt. Die Zahlen für UCS 2.4 sind nur ungefähr. - UCS 3.0 + Laden der Daten: 11,76s (Menge: 762,77KB) + Rendern: einige Millisekunden - UCS 2.4 + Laden der Daten: 35s (Menge: 3,64MB) + Rendern: 45s
Die Performance-Verbesserungen aus Comment 1 sind jetzt eingecheckt
Die Zeiten sollten nochmal geprüft werden, ich schaffe es gerade nicht in einer KVM Instanz auf isala (1GB RAM) 6000 Benutzer im UDM zu listen. Nach 5 Minuten kam eine Fehlermeldung. Wir sollten die access to * Regel in der slapd.conf noch um diese beiden ergänzen: by dn.base="uid=Administrator,cn=users,$ldap_base" write by dn.base="cn=admin,$ldap_base" write Im Idealfall können die einfach nochmal per UCR erweitert werden.
Die ACLs wurden hinzugefügt, zusätzlich wurden die ACLs für uid=root entfernt. Allerdings dauert das Anlegen von Benutzern auf 3.0 per CLI länger als auf einem 2.4 System.
Bisherige Erkenntnisse: * UDM Suche: In der Datei umc/python/udm/ldap.py aus dem Paket univention-management-console-module-udm wird derzeit bei der Suche nach 5000 Benutzern auch jeweils 5000 Mal nach diesen beiden Modulen gesucht: - directories = udm_modules.lookup('settings/directory',... - groups = udm_modules.lookup( 'settings/default', ... Die sollten global zwischengespeichert werden. * OpenLDAP Die Performance von 2.4.25 ist deutlich schlechter als 2.4.23. 2.4.26 ist etwas besser als 2.4.25, aber immer noch deutlich langsamer, vor allem wenn grosse Gruppen geändert werden. Da in Squeeze 2.4.23 ist und das auch die offizielle stabile Version von OpenLDAP ist, sollten wir ebenfalls 2.4.23 verwenden. Vergleichswerte: time ldapsearch -x uid=* -LLL -s one -b cn=users,dc=deadlock5,dc=local >/dev/null 2.6.26: real 0m24.142s 2.6.26: user 0m0.196s 2.6.26: sys 0m0.096s 2.6.23: real 0m13.132s 2.6.23: user 0m0.252s 2.6.23: sys 0m0.068s
(In reply to comment #5) > * UDM Suche: > In der Datei umc/python/udm/ldap.py aus dem Paket > univention-management-console-module-udm wird derzeit bei der Suche nach 5000 > Benutzern auch jeweils 5000 Mal nach diesen beiden Modulen gesucht: > - directories = udm_modules.lookup('settings/directory',... > - groups = udm_modules.lookup( 'settings/default', ... > > Die sollten global zwischengespeichert werden. Die Ergebnisse wurden schon zwischengespeichert, allerdings schlug die Erkennung des Zustands aufgrund eines Typos fehl. Gefixt mit 1.0.203
Die neuen Werte sehen deutlich besser aus (ca. 5000 Benutzer): root@master51:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,dc=deadlock5,dc=local -D cn=admin,dc=deadlock5,dc=local -w $(</etc/ldap.secret) >/dev/null real 0m1.667s user 0m0.436s sys 0m0.044s Wenn anonyous Read erlaubt wird (dieser Wert ist vergleichbar mit Comment #5: root@master51:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,dc=deadlock5,dc=local >/dev/null real 0m11.598s user 0m0.220s sys 0m0.040s Das Anzeigen von 5000 Benutzer dauert in der Oberfläche ca. 12 bis 15 Sekunden. Das Anlegen per CLI von 10 neuen Benutzern dauert auch in der 5000 er Umgebung unter 10 Sekunden.
root@mas77:~# time univention-ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base > /dev/null real 0m13.688s user 0m0.664s sys 0m0.048s root@mas77:~# time univention-ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base > /dev/null real 0m13.688s user 0m0.664s sys 0m0.048s root@mas77:~# root@mas77:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base -D cn=admin,$ldap_base -w $(</etc/ldap.secret) >/dev/null real 0m0.423s user 0m0.188s sys 0m0.024s root@mas77:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base -D cn=admin,$ldap_base -w $(</etc/ldap.secret) >/dev/null real 0m0.377s user 0m0.176s sys 0m0.020s root@mas77:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base -D cn=admin,$ldap_base -w $(</etc/ldap.secret) >/dev/null real 0m0.358s user 0m0.172s sys 0m0.016s root@mas77:~# root@mas77:~# ucr set ldap/acl/read/anonymous="yes" Setting ldap/acl/read/anonymous Multifile: /etc/ldap/slapd.conf root@mas77:~# /etc/init.d/slapd restart Restarting ldap server(s). Stopping ldap server(s): slapd. done. Check database: done Starting ldap server(s): slapd. /etc/init.d/sam. root@mas77:~# /etc/init.d/samba4 restart Stopping Samba 4 daemon: samba.... Starting Samba 4 daemon: samba. Restarting bind9 daemon: . done. root@mas77:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base >/dev/null real 0m7.823s user 0m0.152s sys 0m0.040s root@mas77:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base >/dev/null real 0m6.851s user 0m0.164s sys 0m0.020s root@mas77:~# time ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base >/dev/null real 0m7.007s user 0m0.144s sys 0m0.040s root@mas77:~# An UMC anmelden: < 1 Sek users/user öffnen: ca. 3 Sek (Autosuche weitere 9 Sek) Benutzersuche mit 5000 Usern als Suchergebnis: 10 Sekunden / 32kb Daten Gruppe mit 5000 Mitgliedern öffnen: 4 Sekunden Anlegen der User 5001 bis 5010: 17 Sekunden
5000 User anlegen mit Samba3: 51min 5000 User anlegen mit Samba4: 75min + Sync-Zeit für Listener-Module (>1h)
(In reply to comment #9) > 5000 User anlegen mit Samba3: 51min > 5000 User anlegen mit Samba4: 75min + Sync-Zeit für Listener-Module (>1h) 5000 User anlegen mit Samba4: 75min + Synczeit für Listener-Module (<3h) Benutzer zu 5000er-Gruppe hinzufügen: - Öffnen der Benutzerauswahl zum Hinzufügen: - initiales Öffnen des Dialogs: 12 Sekunden - erneutes Öffnen des Dialogs: < 1 Sekunde - Suchen in der Benutzerauswahl zum Hinzufügen: abhängig von der Ergebnisanzahl: - 10 User → < 1 Sekunde - 100 User → ca. < 2 Sekunden - 5000 User → ca. 12 Sekunden - Gruppe modifizieren/speichern: ca. 6 Sekunden Tests wurden durchgeführt mit aktuellem UCS 3.0, 1GB RAM, 1 CPU
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"