Несвязанный 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-отладчик, и он будет выступать в качестве прокси, но где мне указать ip и порт сервера, потому что в клиенте я уже установил ip и порт для ldap-отладчика?
1 ответ
Там нет ничего, что сразу выскакивает из кода, который вы используете. В моем тестировании UnboundID LDAP SDK намного быстрее, чем Netscape SDK. Хотя вполне возможно, что вы нашли какой-то угловой случай, я бы хотел исключить несколько других возможностей.
Прежде всего, как вы определяете, сколько времени занимает выполнение каждой версии? Используете ли вы время на стороне клиента (например, System.currentTimeMillis(), снова запустите код, System.currentTimeMillis ()) или время на стороне сервера (например, время обработки, указанное в журнале доступа к серверу)? Если различие существует только на стороне клиента, то это определенно может указывать на проблему с SDK, но если различие также появляется на стороне сервера, то, возможно, что-то другое в отправляемых запросах заставляет сервер делать больше работать в одном случае, чем в другом. Вы могли бы потенциально использовать инструмент ldap-debugger, поставляемый с UnboundID LDAP SDK, чтобы точно выяснить, какая связь происходит.
Вы пробовали запускать каждый из них в узком цикле большое количество раз (скажем, 100 000) как часть измерения производительности? Это может помочь гарантировать, что вся необходимая JIT-компиляция была выполнена, что сбои сборки мусора не мешают, и что потенциальная занятость сервера не является проблемой. Если ваш вывод основан на одном прогоне каждого фрагмента кода, то из этого трудно сделать какие-либо реальные выводы.
Если это действительно кажется проблемой на стороне клиента, тогда я был бы признателен, если бы вы предоставили более конкретные детали, чтобы я мог более тщательно исследовать проблему. В частности, было бы полезно увидеть, какие именно запросы отправляются и какие именно записи возвращаются (информация может быть анонимной, чтобы не раскрывать конфиденциальные данные, если она все еще демонстрирует те же характеристики производительности), Вы можете отправить информацию по адресу ldapsdk-support@unboundid.com, если вы хотите предоставить ее в частном порядке.