Медленная обработка запроса на вывод архивной таблицы

Подскажите куда посмотреть что бы понять причины медленной работы ЛЭРС?
Делал вот что: задал довольно широкий период для отображения часовых архивов и засек время за которое они отобразятся на экране, получилось 70 секунд.
Что на сервере: MS SQL Server 2008 R2 Express, Windows Server 2008 R2, RAM 8Gb, Intel Xeon E31220, RAID1
Хотелось бы понять: нормально ли такое время для вышеуказанной конфигурации? Поможет ли ускорить работу переход на MS SQL Server 2008R2 Standart + еще 8Gb RAM?

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

Посмотрите, сколько времени из этих 70 секунд проходит между запросом данных (после нажатия кнопки “Применить”) и отображением в таблице сообщения “Подготовка данных для отображения”.

Второй момент, на который нужно обратить внимание: сколько времени занимает повторный запрос этих же данных (между повторным нажатием кнопки “Применить” и отображением данных). Будут ли это те же 70 секунд?

Узкое место видимо находится на сервере, так как клиент с которого я делал запрос был запущен именно на сервере. Основное время тратится на выборку данных, после того, как появляется надпись, подготовка для отображения, проходит пару секунд и все отобразилось. Повторный запрос не улучшает время. Во вложении данные счетчиков производительности, может они вам помогут.
DataCollector01.zip (26.7 KB)

Тогда давайте смотреть в журнал сервера ЛЭРС УЧЕТ. Включите протоколирование отладочных сообщений в системных параметрах, повторите запрос данных и приложите журнал сервера за текушую дату.

https://yadi.sk/d/V0WCvpR-3H3XM9

Согласно журналу сервера, выборка данных выполняется быстро:

2017-04-17 07:56:20.096 D:3172 CS:34315 Выполняем запрос: sp_GetWaterConsumption @MeasurePointId=403, @StartDate=‘2011-04-29T00:00:00.000’ …
2017-04-17 07:56:20.096 D:3172 CS:34315 SQL-запрос выполнен. Lers.SqlQuery

Нужно искать проблему в другом месте. Нам нужно больше исходных данных. Попробуйте несколько раз подряд обновить данные и засеките время выполнения каждой попытки.

P.S. Пока можно сделать промежуточный вывод: обновление SQL-сервера до редакции Standard данную проблему не решит.
P.P.S. Обновление до Standard повысит производительность работы системы в целом и, особенно, при одновременной работе нескольких пользователей.

Засек, каждый раз значение скачет, вот времена: 68, 75, 75, 77, 69, 73. Это время с момента нажатия кнопки обновить до момента появления данных на экране.
Вот логи ЛЭРСа: https://yadi.sk/d/ngpd_qus3H3eCm

В эти моменты ЛЭРС грузит одно ядро на 100% и проседает оперативная память, на графике видно:
pic.jpg

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

Долго выполняется подготовка данных на клиентской стороне. Весь полученный набор данных анализируется для того чтобы вставить записи с метками “Данные отсутствуют”. Этот процесс был реализован неоптимально и поэтому занимал больше 50% от всего времени, которое требовалось клиентской стороной для отображения данных. Мы оптимизировали этот процесс и в версии R22 отображение часового архива за 6 лет выполняется чуть менее чем за 20 секунд, хотя раньше на это уходило больше минуты.

Какое-то время уходит на упаковку ответа, отправку его по сети, чтение пакета на клиентской стороне и распаковку. Тут ресурсов для оптимизации практически нет, большая часть кода выполняется операционной системой. Однако мы рассматриваем возможности оптимизировать упаковку пакета. Это повысит производительность данного этапа.

Ещё один длительный этап - подготовка данных для отображения в таблице. Если вы просматриваете только часовой архив, на него уходит секунд 10 из 20ти. Если же выбрать для отображения одновременно часовые и суточные данные за такой же период, придётся опять подождать около минуты. Проблема в том, что компонент таблицы занимается группировкой часовых данных. Этот процесс очень ресурсоёмкий и повлиять на него мы не сможем, так как реализован он в сторонних компонентах, которые мы используем.

Спасибо за ответ. Теперь ходя бы ясно, что дело не в SQL сервере.