Разница в производительности Unboundid LDAP и Netscape LDAP

Я пытаюсь обновить веб-приложение, созданное на Java EE, с помощью Tomcat. До сих пор я использовал реализацию Netscape ldap, и теперь я пытаюсь обновитесь до Unboundid Ldap. Проблема в том, что реализация Unboundid имеет очень большую задержку по сравнению с реализацией netscape.

Некоторая информация о том, что я планирую сделать: я хочу получить из LDAP последние 5 записей, поместить их в массив и отобразить этот массив на веб-странице.

EDIT1: я создал 2 примера приложений для тестирования библиотек, используя Java SE. Для каждого теста я приложил исходный код и журнал LDAP на стороне сервера.

Результаты одинаковы, независимо от того, сколько итераций я использую, в среднем требуется гораздо больше времени для получения результатов с использованием реализации UnboundID SDK.

Для Netscape LDAP SDK: код и журнал. Для UnboundID LDAP SDK: код и журнал

EDIT2: я также пытаюсь использовать инструмент ldap-debugger, предоставленный UnboundID, но я не могу понять, как заставить его работать, я вижу, что он принимает в качестве аргументов IP-адрес и порт, на котором для привязки, а клиенты должны подключить ldap-debugger и он будет выступать в роли прокси, но где мне указать ip и порт сервера, ведь в клиенте я уже поставил ip и порт для ldap-debugger ?


java ldap jakarta-ee unboundid-ldap-sdk
person hDan    schedule 28.02.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

В коде, который вы используете, нет ничего, что сразу бросалось бы в глаза. В моем тестировании UnboundID LDAP SDK работает намного быстрее, чем Netscape SDK. Хотя вполне возможно, что вы нашли какой-то крайний случай, я хотел бы исключить несколько других возможностей.

Прежде всего, как вы определяете, сколько времени требуется для выполнения каждой версии? Используете ли вы синхронизацию на стороне клиента (например, System.currentTimeMillis(), снова запустите код, System.currentTimeMillis()) или синхронизацию на стороне сервера (например, время обработки, указанное в журнале доступа к серверу)? Если разница существует только на стороне клиента, то это определенно может указывать на проблему с SDK, но если разница проявляется и на стороне сервера, то, возможно, есть что-то другое в отправляемых запросах, что заставляет сервер делать больше. работать в одном случае, чем в другом. Потенциально вы можете использовать инструмент ldap-debugger, поставляемый с UnboundID LDAP SDK, для точного исследования связи.

Пробовали ли вы запускать каждый из них в узком цикле большое количество раз (скажем, 100 000) в рамках измерения производительности? Это может помочь гарантировать, что вся необходимая компиляция JIT была выполнена, что сбои со сборкой мусора не мешают, и что потенциальная занятость сервера не является проблемой. Если ваш вывод основан только на одном прогоне каждого фрагмента кода, то из этого трудно сделать какие-либо реальные выводы.

Если это действительно проблема на стороне клиента, я был бы признателен, если бы вы предоставили более конкретные сведения, чтобы я мог более тщательно изучить проблему. В частности, было бы полезно видеть, какие именно запросы отправляются и какие именно записи возвращаются (информация может быть анонимной, чтобы она не раскрывала никаких конфиденциальных данных, пока она по-прежнему демонстрирует те же характеристики производительности). . Вы можете отправить информацию по адресу [email protected], если предпочитаете предоставлять ее в частном порядке.

person Neil Wilson    schedule 28.02.2014