Скоро буду участвовать в проекте ускорения работы кастом клиента-терминала.
Архитектура традиционная 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?

Мой подход (отделить/сузить запрос до необходимых колонок, отделить форму выбора заказчика от тяжеловесной формы редактирования реквизитов заказчика) принес некоторые результаты, но не дотягивает до цели в 0.5-1 секунды, и не является универсальным.

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

Думаю, как сделать за полсекунды.

Значит придётся программировать background fetch.


Да, похоже на это.

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

Затрудняет вопрос вычисления дельты между клиентом и еще неосуществленным запросом.
Возможно что для этого, как для инкрементальных апдейтов материализованных представлений,
есть готовые решения, но я пока ничего не нагуглил.

Запрос в общем случае считается тяжеловесным, секунды.
Дельта-запрос который касается только измененных строк - на 2-3 порядка быстрее,
но чтобы построить дельта-запрос, надо знать какие строчки, а для этого нужен полный запрос.

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

Что важно, я упомянул: сеть пропускной способностью в гигабиты, все компоненты звена в одном дата центре, и измерение данных показало, что в них не попала "шелуха", т.е. их размер сочетается с моими ожиданиями. Соответственно, места для оптимизации на стороне сети мало. То, что есть, работает близко к оптимальному режиму для моей задачи.

Вроде, придумал. Основано на книжных знаниях, поэтому как получиться - покажет практика.

Исходные: медленный запрос "заказчики" с 20 тыс строк на 100 колонок, многие вычисляемые
Исполнение запроса: 10сек. Обработка на сервере - пренебрегаем (около 0.1 сек), заполнение контролов и грида - 2 сек.
Все вместе, если тянуть все колонки - 12 сек. Если тянуть только дешевые колонки - 2 сек (SQL срабатывает мгновенно)
Цель - моментально показать список заказчиков, с возможностью показа некоторых медленно вычисляемых полей.

Шаг 1: заменить медленный запрос на materialized view, "fast update on commit". Мой 11.2 вроде это умеет.
Теперь SQL сам будет построчно править вью, поддерживая полный список заказчиков готовым для запроса.
Это почти до нуля снижает скорость запроса, общее время - 2 сек из-за медленных виджетов клиента.

Шаг 2: Научить клиента вместо убивать/создавать форму, прятать/показывать собранную форму и само-синхронизироваться с (1).

Если не найду грид-виджет с само-синхронизацией, остается вариант более трудоемкой дельты вручную:

Шаг 3: раз в сутки(неделю, час) снять копию данных materialized view. Назовем их "ночной список заказчиков". От ночного списка строятся дельты.

Шаг 4: Научить клиента принимать дельты для построчной коррекции.

(1) проще всего. (2) выходит за рамки раздела Оракла. (3) может быть тоже materialized view, update on demand

Это должно позволить вызвать поп-ап за <= 0.2 секунды, что в глазах пользователя приравнивается к мгновенному.

После нескольких неудачных попыток, получилось создать первое представление с "fast update on commit".

Написал пару скриптов из двух сессий, пытаясь "споймать" промежуток времени между обновлением таблиц-источников, и обновлением моего представления, не словил. Ощущение, что обновление происходит синхронно.

Материализованные представления почему-то описываются в контексте "складов данных", непохоже что они используются часто в других ситуациях, но вот пригодилось. В моем случае, эта фича работает в точности как я ожидал, в 10 раз ускоряя клиентский запрос.

Были дополнительные улучшения в этой области в 12.х (возможность записи в материализованное представление), но придется с ними повременить.

Поделюсь, что узнал и испытал про MV.

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

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

Например, если есть селф джойн, то запрещен внешний джойн. Анси джойн просто запрещен для refresh fast on commit with SCN. Пришлось плюсики ставить.

В итоге, скорость чтения возрасла в пять раз (согласно autotrace), скорость записи не проверял, т.к. они строка в минуту или меньше.

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