Скоро буду участвовать в проекте ускорения работы кастом клиента-терминала.
Архитектура традиционная 3-звенная: Win32 клиент на стареньком Дельфи - Вин32 сервер на нем же - Оракл 11.2
Сотни интерактивных Windows клиентов на медленном железе через один апп сервер доступаются к одной базе.

За терминалами сидят живые люди, которых раздражают задержки и подвисания. Нажатие кнопки может привести к 10-секундному ожиданию, что неприемлемо. Клиенты (виртуально) находятся в одном дата центре с серверами, поэтому сеть между клиентами и серверами считается очень быстрой.

С задачами оптимизаций я знаком, но по совсем другим ситуациям (интел железо, спутники связи, дизайн файловых систем), про базы знаю очень мало, про оптимизацию Оракла - вообще ничего. Должно быть интересно и познавательно.

Для разминки, выбрал конкретный сценарий и сделал несколько замеров скорости, а также написал немного предварительного кода.

Сценарий: список заказчика, который выскакивает по кнопке "выбрать заказчика".
Лучшее время: 300-500 строк за 3-5 секунд (если уже выбран фильтр)
Худшее время: десятки тысяч строк за 30-60 секунд (если фильтр отключен)

Для интерактивных приложений, UI считается "мгновенным" если укладывается в 200 миллисекунд, и "быстрым" если < 500мс.
При длительности ожидания более 200мс принято показывать индикатор занятости, обычно курсор, это уже делается.
При длительности ожидания более секунды (это уже плохо) желательно показывать индикатор прогресса

Начальная цель: уложиться в одну-две секунды для всех значений фильтра.

Начал с замеров, чтобы понять где и что тормозит.

Замер 1: исключить сеть как фактор.
Ранее упоминалось что сеть считается очень быстрой и не потребует оптимизации.
Предположения полагается проверять, поэтому мой сотрудник, системный администратор исключительных талантов, помог сделать замеры объема сетевого трафика. Получилось около 50 байтов на строку (используется сжатие между клиентом и сервером).
Вывод 1 : сеть не является фактором, т.к. в один мегабайт помещается 20 тыс строчек, а мегабайт по гигабитам летает быстро.

Замер 2: скорость железа клиента как фактор
Замеры показали что скорость сценария зависит от скорости железа. Разница между "стандартным" и "самым быстрым" примерно вдвое.
Вывод 2 : оптимизация кода на клиенте имеет смысл, и скорее всего будет необходимой.

Замер 3: скорость исполнения запроса на сервере.
Запрос достаточно сложный, сотни строк и десяток таблиц. Немного поломал голову, как исполнить запрос без вывода данных на экран, наконец нашел "set autotrace traceonly". Получил пять секунд для полного запроса на все имеющиеся строчки.
Вывод 3 : для достижения цели будет необходимо изменить запрос.

Замер 4: влияние среднего звена на общую задержку
Этот замер отложил, т.к. код сервера законсервирован. Влияние возможно есть, оно будет известно лучше после оптимизации кода клиента и запроса. Уточнил у своего гуру, что архитектура "store and forward", т.е без пайплайнинга (результат запроса отдается серверу одним куском, а потом тот отдает его клиенту). Без пайплайнинга время исполнения SQL запроса и время получения/рендеринга текста на экране складываются в общую паузу ожидания, и эффект оптимизаций тоже складывается.

Сразу столько комментариев! Спасибо.

Попробую ответить на все.

Leonid Kudryavtsev> А где тут "Архитектура традиционная 3-звенная" ?
(Оракл) --- (Апп сервер) ---- (Клиент)
Апп сервер обслуживает все сотни клиентов, разговаривает с ораклом через 10-20 сессий.
Я понимаю, такая архитектура называется 3-звенкой, хотя термин чаще используется для вэбсайтов. Верно?

graycode> А при чем тут Оракл?
Я описываю задачу в целом для полноты контекста, и чтобы было интересно.
Вопросы оптимизации клиента довольно простые, на мой первый взгляд.
У меня будут вопросы по оптимизации, которые затронут Оракл, с которыми мне возможно помогут местные эксперты.

env> Какой сакральный смысл в передаче десятков тысяч строк на клиента?
Это очень правильный вопрос, один из тех что я собираюсь задать. Ответ на этот вопрос может значительно повлиять на объем работ и результат. Леонид частично на него ответил. Обычно "всех" хотят видеть руководители, а они жалуются громче рядовых сотрудников.

Leonid Kudryavtsev> Т.к. фильтров может быть бесконечно много,
Фильтр ограниченной сложности. Когда я написал "при всех возможных значениях фильтрА", я имел в виду самое неблагоприятную для скорости комбинацию значений. На данный момент это пустой фильтр.

Давайте на время отложим комментарии "дело труба, беги оттуда".
Я очень уважаю моих сотрудников и учредителей, и эта задача мне интересна.

На данный момент я собрал прототип который показывает полный список за 1.5-2 секунды.
Это лучшее что мне удалось сделать без внесения изменений в архитектуру. Через пару минут расскажу что уже сделал.

Дальше будет труднее, и наверное интереснее как вам, так и мне.

Это один из вариантов.

Я вчера в первый раз ковырялся в DB контролях Дельфи (они какие-то кастом).
Я заметил что ленивый фетч присутствует в настройках, но не используется нигде в приложении.
Есть ньюанс, что поиск по Ctrl-F (вместо настройки фильтра) это самый ходовая команда у пользователей, ее нужно сохранить.
Также, при ленивой подкачке возникнет дополнительная работа по обработке сортировок по колонкам с сохранением позиции выбранной строки. Это задача чревата большим количеством тестирования. Поскольку тестера мы не предусмотрели, я пока откладываю варианты связанные с повышенной тестовой нагрузкой.

Как раз пустой фильтр для стандартных дельфийских компонент практически идеальный случай.
Если даже его вы сумели вытянуть только на секунду... См сообщение выше.


Мы оба говорим про сервер-сайд фильтр, который передается на сервер, и уменьшает количество строк, так?

Пустой фильтр сегодня дает максимальное количество строк, а задержка в исполнении операции показа заказчиков растет с числом строк. На этом основании я заключил что пустой фильтр на сегодня самый медленный. (ну и прямых измерений, конечно)

Что я напрототипил, и какие нашел грабли:

Скорость рендеринга.
У меня не было ясности что старая дельфовая обертка грида позволяет показать 20тыс строк за секунду в моей среде.
Небольшой тест позволил это проверить, результаты были обнадеживающие - грид достаточно быстрый

Конфигурация списка
По умолчанию выводится 6 колонок, разрешается добавить еще 70, самых эзотерических)
Резалт сет всегда содержит все колонки, многие из которых вычисляемые.

Изолированность изменений
Это был первый большой сюрприз. Оказалось, поп-ап список заказчиков (как адресная книга в аутлуке) использует не только запрос, но и всю дельфи инфраструктуру от большого экрана просмотра/добавления/изменения заказчиков. Я не разобрался все, что она тянет, но там немало. Имя SQL запроса - атрибут типа, поэтому если я хочу менять запрос под свои цели, надо отделять поп-ап выбора заказчика от кода "большого экрана" который позволяет редактирование и подробный анализ.

Испытал пару подходов.
1) склонировал экран редактирования заказчиков, начал выбрасывать все ненужное. Походу рассмотрел архитектуру клиента, довольно умный хлопец его писал. В (теперь отдельном) запросе удалил опциональные колонки. Получил примерно 3 секунды.

2) собрал "с нуля" минимальную форму базового класса с базовыми виджетами позволяющий показать список, но еще отвечающий параметрам архитектуры клиента, чтоб его можно было обозначить как "попап". С тем же запросом получил 1.5-2 секунды. Это около 10К строк в секунду без "ручного кода" в клиенте - только виджеты на форме. Ctrl-F работает.

На этом пока остановился - ограничение скорости заполнения грид контроля в моей среде. На более быстром компе это в 2-3 раза быстрее.

Левые компоненты вроде бы умеют, хотя еще не проверял, а в проекте они только используются в режиме целиком.

У меня есть требование сохранить поиск по Ctrl-F (это наверное можно извернуться, передав в фильтр и ре-фетч, сообщив серверу критерий поиска, номер выбраной строки и критерий сортировки),

и мне не совсем понятно как будет работать сортировка по колонкам с сохранением текущей строки, я предполагаю компоненты все это сами умеют делать, если им известен PK?