Модуль eldap Эрланга тайм-аут в поиске с большим количеством результатов - PullRequest
Новая
       83

Модуль eldap Эрланга тайм-аут в поиске с большим количеством результатов

0 голосов
/ 28 января 2020

Проблема

Я использовал Exldap для интеграции моего приложения с сервером Active Directory. Для некоторых функций, не поддерживаемых Exldap, я напрямую вызывал базовые функции Erlang eldap. Я столкнулся с огромной проблемой производительности сегодня, и я пытаюсь выяснить, что происходит. Чтобы сузить проблему, я обошел Exldap и сделал все напрямую, используя eldap.

Все, что я пытаюсь сделать, это перечислить всех членов группы largi sh (~ 380 члены). Когда я выполняю поиск, используя утилиту командной строки ldapsearch, я получаю все результаты, отображаемые за доли секунды: 

$ time ldapsearch \
  -H ldaps:/ldap.example.edu:636 \
  -D 'CN=My Bind DN,OU=Service Accounts,DC=department,DC=example,DC=edu' \
  -w 'bind_password' \
  -b 'DC=department,DC=example,DC=edu' \
  -s sub \
  '(memberOf=CN=Staff,OU=Staff,DC=department,DC=example,DC=edu)'

# [379 responses / ~25000 lines of output omitted]
# numResponses: 379
# numEntries: 377
# numReferences: 1
0.05s user 0.05s system 25% cpu 0.407 total

Когда я выполняю точно такой же поиск, используя точно такие же параметры, используя: eldap: 

{:ok, conn} = :eldap.open(['ldap.example.edu'], port: 636, timeout: 50000, ssl: true)

:eldap.simple_bind(
  conn,
  'CN=My Bind DN,OU=Service Accounts,DC=department,DC=example,DC=edu',
  'bind_password'
)

base = 'DC=department,DC=example,DC=edu'
scope = :eldap.wholeSubtree()
filter = :eldap.equalityMatch('memberOf', 'CN=Staff,OU=Staff,DC=department,DC=example,DC=edu')

:eldap.search(conn, base: base, scope: scope, filter: filter)

# 50 seconds pass
{:error, {:gen_tcp_error, :timeout}}

Я не могу шпионить за всем разговором по проводной связи, потому что он использует SSL, но я могу сказать, что версия ldapsearch приводит к полезной нагрузке 676 КБ, тогда как версия eldap только сбрасывает 323 Кбайт до того, как связь прекратится и поиск (в конце концов) прекратится.

Дальнейшие исследования

Методология

Я повторил эксперимент на двух других серверах: a samba сервер и openldap сервер. Оба сервера работали в контейнерах Docker, порты 389 и 636 были перенаправлены на хост. Оба были настроены так, чтобы разрешать как незашифрованные, так и зашифрованные соединения, используя самозаверяющие сертификаты для соединений SSL. Оба были загружены (используя ldapadd и файл LDIF) с 500 тестовыми записями objectClass=person. Для простоты я не беспокоился о членстве в группах; моей целью было просто запросить все 500 записей, используя их общий OU в качестве основы для поиска и фильтрации по objectClass.

Results

  • Незашифрованные соединения работают нормально для все клиенты на обоих серверах, возвращая все 500 результатов за долю секунды
  • Зашифрованное соединение с openldap также отлично работает для всех клиентов с аналогичным временем ответа
  • Ruby 's net-ldap и утилита ldapsearch работают нормально при использовании SSL-соединения с samba
  • eldap превышением времени получения большого набора результатов от samba по SSL-соединению, так же, как это происходит в Active Поиск в каталоге, с которого началось все это испытание
  • Все поиски работают должным образом на всех серверах / протоколах с использованием Apache Directory Studio

Другие поиски работают нормально; это просто время ожидания для одного с несколькими сотнями результатов. Я не уверен, где go отсюда. Буду признателен за любую помощь или понимание.

...