медленный AD

← →
vasa777 (2012-08-14 10:46) [0]

есть соедиенние через ldap к AD ADO (Provider=ADsDSOObject;) и SQL
в цикле получаю инфу для формирования дерева (табличка тоже есть, но не важно)

// кусок кода

i1:=dm1.ADOQuery1.RecordCount;
sl:=tstringlist.Create;
for i:=1 to i1 do begin
application.ProcessMessages;
statusbar1.Panels[0].Text:=inttostr(i)+"/"+inttostr(i1);
dm1.ADOQuery1.RecNo:=i;
// тут получаю инфу по пользователям (почти все поля)
...
if vartype(adoquery1CanonicalName.Value)<>varNull then sl.Add(string(adoquery1CanonicalName.Value[0])); // пример получения одного значения
end;

Вопрос: все это работает, но довольно медлено (даже если выполняется на самом DC) примерно 2 записи в секунду получается вытаскивать (всего 500 тестовых записей пользователей).
Нельзяли как то это все ускорить? В свойствах соединения ADO пробовал кэш включить, отключить таблицу при проходе цикла и прочее... Все равно както не быстро. Понимаю что полей много, но там же не мегобайты данных, текст один.

← →
sniknik © (2012-08-14 11:20) [1]

> Нельзяли как то это все ускорить? В свойствах соединения ADO пробовал кэш включить, отключить таблицу при проходе цикла и прочее...
а нужно всего лишь правильно, по справке работать с датасетом.

← →
kilkennycat © (2012-08-14 11:21) [2]

отдельной нитью без всяких процессмессаджев

← →
AV © (2012-08-14 11:28) [3]

странно, 3 секунды на весь домен практически, около 2000 юзеров

ConnectionString =
Provider=ADsDSOObject;Encrypt Password=False;Integrated Security=SSPI;Data Source=LDAP://domain.ru;Mode=Read;Bind Flags=0;ADSI Flag=-2147483648

sql.text =
select
sn,
givenname,
company,
mail,
title,
telephonenumber
from "LDAP://domain.ru"
where objectCategory = "person"
order by name

← →
DVM © (2012-08-14 23:54) [4]

> AV © (14.08.12 11:28) [3]
> странно, 3 секунды на весь домен практически, около 2000
> юзеров

странно, что сразу 2000, в LDAP есть ограничение больше 1000 пользователей не возвращает обычно за раз.

← →
AV © (2012-08-15 08:14) [5]

> DVM © (14.08.12 23:54) [4]

может, регулируется?
только что, 1820 записей, это уже не чистый запрос, а в -sourse - дб.гриде
ну и не3, а секунд 5, максимум

← →
DVM © (2012-08-15 10:03) [6]

> AV © (15.08.12 08:14) [5]

> может, регулируется?

да, регулируется, в реестре кажется.

← →
sniknik © (2012-08-15 10:13) [7]

> ну и не3, а секунд 5, максимум
5 сек ты считаешь загрузку в рекордсет (Open), или + такое же бездарное/ламерское перекладывание в стринглист как у автора?

← →
vasa777 (2012-08-15 10:23) [8]

Удалено модератором
Примечание: Не наезжай, плохо кончишь

← →
AV © (2012-08-15 10:24) [9]

от 3х до 5 секунд это Open с отображением в DBgrid

← →
vasa777 (2012-08-15 10:24) [10]

Удалено модератором
Примечание: Говорю плохо кончишь

← →
vasa777 (2012-08-15 10:52) [11]

проблему я решил кстати. основную задержку давали фотографии, которые были больших объемов, при обрабтке и сортировки.

большие объемы надо обрабатывать либо заранее, если исходные не нужны, либо по мере отображения/использования. а каким образом размер фотографий влияет на скорость сортировки - непонятно. пиксельно-яркостностный критерий учитывается? :)

> [11] vasa777 (15.08.12 10:52)
> основную задержку давали фотографии

А это деза бвла?

> [0] vasa777 (14.08.12 10:46)
> Понимаю что полей много, но там же не мегобайты данных,
> текст один.

> [12] kilkennycat © (15.08.12 11:15)
> а каким образом размер фотографий влияет на скорость сортировки
> - непонятно. пиксельно-яркостностный критерий учитывается?:)

Щас окажется, что на сервере хэш функция фильтра распознавания лиц подключена.

медленный AD Найти похожие ветки