Доступны результаты (http://red-hat-moscow-times.blogspot.com/2008/02/ldap.html) измерения производительности Fedora Directory Server и OpenLDAP. В тесте оценивалась скорость выполнения операций одиночного чтения, которые составляют 90% от всех запросов к LDAP серверу.При запросе по атрибуту для которого построен индекс, скорость серверов примерно одинаковая. В операциях по добавлению данных и при выполнении запросов не проиндексированных полей лидирует Fedora Directory Server.
Выводы:
На небольших базах (до 50 000 записей) и при небольшом количестве параллельных запросов FDS/RHDS и OpenLDAP ведут себя очень схоже. Разница в производительности не дает о себе знать, если грамотно использовать индексы. Однако, OpenLDAP начинает серьезно отставать от конкурента по времени добавления записей, при неструктурированном поиске, а также при увеличении параллелизма.
В качестве вывода можно сказать следующее - для простых и небольших баз OpenLDAP хорошо справляется со своей работой. Тем не менее, для более масштабных и загруженных LDAP серверов FDS подходит лучше, особенно учитывая его богатый функционал, отсутствующий у OpenLDAP, а именно
- Возможность поддержания нескольких партиций LDAP-каталога на одном сервере
- Мультимастеринг (говорят, в devel ветке openldap он тоже есть, тем не менее мы используем стабильную версию)
- Более гибкие возможности репликации
- Репликацию с ADURL: http://red-hat-moscow-times.blogspot.com/2008/02/ldap.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=14054
Прошляпили один момент, сводящий на нет всю "оценку".Из OpenLDAP Admin Guide:
"back-ldbm was both slow and unreliable. Its byzantine indexing code was prone to spontaneous corruption, as were the underlying database libraries that were commonly used (e.g. GDBM or NDBM). back-bdb and back-hdb are superior in every aspect, with simplified indexing to avoid index corruption, fine-grained locking for greater concurrency, hierarchical caching for greater performance, streamlined on-disk format for greater efficiency and portability, and full transaction support for greater reliability."Документацию не читаем, фигачим конфиги по дефолту.
>[оверквотинг удален]
>Из OpenLDAP Admin Guide:
>"back-ldbm was both slow and unreliable. Its byzantine indexing code was prone
>to spontaneous corruption, as were the underlying database libraries that were
>commonly used (e.g. GDBM or NDBM). back-bdb and back-hdb are superior
>in every aspect, with simplified indexing to avoid index corruption, fine-grained
>locking for greater concurrency, hierarchical caching for greater performance, streamlined on-disk
>format for greater efficiency and portability, and full transaction support for
>greater reliability."
>
>Документацию не читаем, фигачим конфиги по дефолту.+1 к морали :) также считаю что тесты провалены изначально.
хмммм. Если оба сервера использовали ldbm как бакенд, то об чем это говорит, раз FDS выдала лучшие результаты при дефолтных настройках?Недавно посмотрел FDS - впечатления крайне положительные, помимо кучи наворотов навроде тыканья мышкой acl'ок, удаления/добавления корневых суффиксов на лету и проч. У него - очень и очень серьезные перспективы. Но думаю, OpenLDAP тоже со счетов не надо списывать - он найдет себе нишу во встраиваемых системах.
Ух - вспомнил как тут воняло, когда умные люди говорили что опенлдап - только для крохотных сеточек :) Вот вам прооф от других таких же красноглазиков!PS: Интересно их померять с Novell DS'овским LDAP'ом ... наверное порвёт обоих :)
>Ух - вспомнил как тут воняло, когда умные люди говорили что опенлдап
>- только для крохотных сеточек :) Вот вам прооф от других
>таких же красноглазиков!`Умные люди' не умеют его настраивать. А вот закрытые недоподелия не нужны.
> А вот закрытые недоподелия не нужны.Факт.
Дык вроде и опенлдап и федорас оба открытые, хотя и не помню точно под какими лицензиями...
>`Умные люди' не умеют его настраивать. А вот закрытые недоподелия не нужны.А ты научи :) Там юзер аккаунтов 60К - территориально распределённо ... Поверь мне малыш - перед тем как _пришлось_ _купить_ NDS - секс с OpenLDAP был неслабый :) Оно умерло. Наверно мы его любили недостаточно нежно :))))
Если бы OpenLDAP на таких объёмах работал - я бы тут не умничал. Когда нибудь доточат - вон мультимастер даже уже есть (тогда - не было)
>PS: Интересно их померять с Novell DS'овским LDAP'ом ... наверное порвёт обоихЕсли честно, лично нам уже не особо интересно. Есть субъективный эмпирический факт - FDS/RHDS вполне держит любую нагрузку, с которой нам приходилось сталкиваться. Еще есть факт, что за счет мультимастеринга и репликации он вполне держит инфраструктуру AOL (хотя лично с такими масштабами работать и не приходилось).
Поэтому на этой стадии мы в своих тестах ставим точку. Если есть альтернативные мнения и пожелания, что еще хотелось бы видеть, - дайте знать (лучше всего коментом к первоисточнику, чтобы мы точно заметили).
// Один из авторов
Вроде как multimastering есть в openldap 2.4 и это не devel
>Вроде как multimastering есть в openldap 2.4 и это не develверсия openldap у них не указана.
Есть, но это не stable, это latest - его никто не будет использовать в серьезных системах. Увы.