Методика тестирования
Мы сосредоточились на задачах, которые занимают 90+% всех операций, выполняемых с LDAP-серверами, а именно - операциях одиночного чтения. Под одиночным чтением подразумевается соединение клиента и сервера, аутентификация клиента на сервере, считывание одной записи о отсоединение.Для этого были сгенерировано плоское дерево, моделирующее простую структуру с большим количеством "пользователей" Иначе говоря, мы сделали N записей вида
dn: uid=user00000,ou=People,dc=example,dc=com
objectClass: account
objectClass: posixAccount
uid: user00000
cn:User User
loginShell: /bin/bash
uidNumber: 100000
gidNumber: 100000
homeDirectory: /home/user00000
gecos: User Userovich 00000
После этого мы измеряли на одной и той же системе, в которой запущен только LDAP-сервер время выполнения 1000 последовательных единичных чтений. При этом мы использовали чтения по RDN (аналог primary key в DBMS), по атрибуту, по которому построен индекс, а также по атрибуту, по которому индекс не построен. При этом оба сервера были настроены использовать одинаковую структуру индексов и одинаковый backend (LDBM).
Для произведения 1000 случайных чтений мы предварительно генерировали последовательность псевдослучайных чисел в необходимом диапазоне, после чего утилитой time измеряли время произведения 1000 вызовов ldapsearch по заданному файлу с последовательностью.
Поскольку мы меняли сервера на одной системе, а также для увеличения репрезантативности тестов, тесты прогонялись 20 раз подряд на разных последовательностях, после чего усреднялись результаты последних 10. Первые 10 прогонов симулировали "разогрев" сервера после перезапуска.
Результаты тестов приведены ниже.
Результаты тестов
Итак, результаты тестов. для начала 1000 четний по RDN и по индексу. Мы представляем результаты единым графиком и таблицей потому, что они все равно получились очень близкие, что неудивительно. Расхождение между этими двумя тестами не превышает погрешности наших измерений.| 1000 чтений по RDN/индексу | ||
| ## записей | FDS | OpenLDAP |
| 1000 | 4,39 | 4,8 |
| 5000 | 4,46 | 4,85 |
| 10000 | 4,54 | 4,89 |
| 50000 | 4,65 | 4,91 |
Теперб результаты 1000 чтений по атрибуту, индекс по которому не построен. В нашем случае мы использовали атрибут homeDirectory. Предвидя скептические возгласы, скажу, что подобные вещи (поиск по атрибуту без индекса) не должны встречаться в хорошо спланированном LDAP-дереве. Тем не менее результаты вполне имеют право на жизнь, а также наглядно иллюстрируют пользу индексов.
| 1000 чтений без индекса | ||
| ## записей | FDS | OpenLDAP |
| 1000 | 11,82 | 25,25 |
| 5000 | 92,99 | 124,63 |
| 10000 | 232 | 303 |
| 50000 | 340 | 1047 |
Ну и наконец, тест времени заполнения базы. Это есть непосредственно время выполнения ldapadd для файла, содержавшего нашу базу переменного размера. Если помните, LDAP не гарантирует транзакционности, а также неэффективен при операциях на запись. Некоторые люди поэтому предпочитают иметь DBMS (например PostgreSQL) для хранения данных, а LDAP используют для создания копии, которая работает только на чтение. | Добавление записей | ||
| ## записей | FDS | OpenLDAP |
| 1000 | 2,09 | 20,96 |
| 5000 | 10,9 | 216,08 |
| 10000 | 23,56 | 440 |
| 50000 | 183 | 1181 |
Ну и наконец мы провели еще один тест. Дождавшись таки пока OpenLDAP импортирует базу в 100 000 записей, мы провели тест на 1000 произвольных чтений по индексу при 200 параллеьно работающих потоках. Для этого мы запустили 200 потоков предыдущих тестов, измеряя прохождение одного из них. Результаты получились следующие:Red Hat Directory Server - 772 секунды
OpenLDAP - 996 секунд
Выводы
Выводы из этих тестов достаточно очевидны. На небольших базах (до 50 000 записей) и при небольшом количестве параллельных запросов FDS/RHDS и OpenLDAP ведут себя очень схоже. Разница в производительности не дает о себе знать, если грамотно использовать индексы. Однако, OpenLDAP начинает серьезно отставать от конкурента по времени добавления записей, при неструктурированном поиске, а также при увеличении параллелизма. Именно поэтому мы остановились на 50 000 записей - OpenLDAP о-о-очень долго их импортировал.
В качестве вывода можно сказать следующее - для простых и небольших баз OpenLDAP хорошо справляется со своей работой. Тем не менее, для более масштабных и загруженных LDAP серверов FDS подходит лучше, особенно учитывая его богатый функционал, отсутствующий у OpenLDAP, а именно
- Возможность поддержания нескольких партиций LDAP-каталога на одном сервере
- Мультимастеринг (говорят, в devel ветке openldap он тоже есть, тем не менее мы используем стабильную версию)
- Более гибкие возможности репликации
- Репликацию с AD
2 комментария:
> При этом оба сервера были настроены использовать одинаковую структуру индексов и одинаковый backend (LDBM).
"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."
Бэкэнд LDBM был выбран из-за того, что Fedora Directory Server предпочитает использовать его. В случае использование BDB на одном сервере и LDBM на другом, проявились бы также различия LDBM и BDB, что на мой взгляд уменьшило бы объективность происходящего.
Кроме того LDAP с BDB заметно дольше заправляется данными и строит индексы.
Отправить комментарий