Автор Тема: Раздел 5. Производительность  (Прочитано 3196 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Droni

  • Модератор
  • Пользователь
  • *****
  • Сообщений: 97
« Последнее редактирование: Май 06, 2015, 02:13:46 pm от Droni »

Neo111

  • Пользователь
  • **
  • Сообщений: 58
Re: Раздел 5. Производительность
« Ответ #1 : Апрель 29, 2015, 04:46:00 pm »
5.5 – 2 (1 вариант точно не верен в тесте)
5.13 – 1
5.14 – 3
5.16 – 4
5.19 - 1

Neo111

  • Пользователь
  • **
  • Сообщений: 58
Re: Раздел 5. Производительность
« Ответ #2 : Апрель 29, 2015, 05:17:24 pm »
5.28

Рассуждаю так:
1 вариант - минимизация клиент-серверных вызовов все же более актуальна для нестабильных каналов связи, а для хороших каналов лучше ставить динамическое считывание
2 вариант - реализуем только если количество отображаемых данных не очень большое
3 вариант - не вариант вообще
4 вариант - кажется самым правильным, т.к. в запросах динамических списков вообще не рекомендуется использовать соединения с виртуальными таблицами
« Последнее редактирование: Апрель 29, 2015, 05:18:55 pm от Neo111 »

Droni

  • Модератор
  • Пользователь
  • *****
  • Сообщений: 97
Re: Раздел 5. Производительность
« Ответ #3 : Апрель 29, 2015, 05:22:29 pm »
5.5 – 2 (1 вариант точно не верен в тесте)
5.13 – 1
5.14 – 3
5.16 – 4
5.19 - 1
Согласен.

Droni

  • Модератор
  • Пользователь
  • *****
  • Сообщений: 97
Re: Раздел 5. Производительность
« Ответ #4 : Апрель 29, 2015, 05:31:02 pm »
5.28

Рассуждаю так:
1 вариант - минимизация клиент-серверных вызовов все же более актуальна для нестабильных каналов связи, а для хороших каналов лучше ставить динамическое считывание
2 вариант - реализуем только если количество отображаемых данных не очень большое
3 вариант - не вариант вообще
4 вариант - кажется самым правильным, т.к. в запросах динамических списков вообще не рекомендуется использовать соединения с виртуальными таблицами
Выбрал 1, т.к. считаю, что отключив динамическое считывание мы будем делать select для заполнения списка по TOP 1000, с динамическим считыванием по TOP 20 или 42 (точно не помню), т.е. при скроле списка будет больше запросов СУБД. Понятно что без дин. считывания размер передаваемых данных с сервера на клиент будет большим, но говорят же что канал широкий и стабильный.
Можно более развернутую аргументацию или пруф на "более актуальна для нестабильных каналов связи".
Вариант 4, так же подходит для ответа.

Neo111

  • Пользователь
  • **
  • Сообщений: 58
Re: Раздел 5. Производительность
« Ответ #5 : Апрель 29, 2015, 07:35:20 pm »
Аргументация предпочтительности динамического считывания данных например тут:

http://its.1c.ru/db/v8std#content:2149184381:hdoc:_top:%D0%B4%D0%B8%D0%BD%D0%B0%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5%20%D1%81%D1%87%D0%B8%D1%82%D1%8B%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85



Цитировать
Необходимо выбрать один из трех режимов работы динамического списка:
Динамическое считывание данных включено (рекомендуется). Используются запросы, выбирающие записи в количестве приблизительно соответствующем количеству видимых строк в таблице.
Динамическое считывание данных выключено, задана основная таблица. Используются запросы, выбирающие по 1000 записей в буфер на сервере, по мере необходимости данные передаются на клиент.  Менее эффективно, чем динамическое считывание
Динамическое считывание данных выключено, основная таблица не задана. Запрос выполняется «как есть». В буфере накапливаются данные, начиная с 1000 записей. Чем ближе к концу списка, тем больше записей.  Можно использовать только для заведомо маленьких выборок.

По поводу нестабильных каналов связи. Я где-то читал, что для таких каналов особенно актуальным является минимизация серверных вызовов (т.к. связь периодически пропадает). И вот для таких случаев лучше отключать динамическое считывание данных. Пакет передачи будет больше, но вызовов будет меньше.
« Последнее редактирование: Апрель 29, 2015, 07:36:58 pm от Neo111 »

Neo111

  • Пользователь
  • **
  • Сообщений: 58
Re: Раздел 5. Производительность
« Ответ #6 : Апрель 29, 2015, 07:44:16 pm »
Еще по ходу 5.1 - 1

http://v8.1c.ru/o7/201312opt/index.htm

Цитировать
Для оценки скорости работы интерфейса можно замерять максимальное время отклика на одно интерактивное действие пользователя. Нужно всячески стремиться к тому, чтобы оно не превышало 1 секунду.

Чем эту секунду замерять? У нас есть показатели производительности, можно пытаться использовать их. Ещё можно пытаться замерять время отклика с помощью дополнительного кода на встроенном языке. Это всё неправильно. В итоге мы получим совсем не то время, которое на практике видит пользователь. Особенно неправильным оно будет в веб-клиенте, в котором присутствует большое количество асинхронности. В результате время, когда начинает исполняться прикладной код (например, срабатывает обработчик ожидания), может сильно отличаться от того времени, когда форма реально прорисуется и ей можно будет начать пользоваться.

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

Droni

  • Модератор
  • Пользователь
  • *****
  • Сообщений: 97
Re: Раздел 5. Производительность
« Ответ #7 : Апрель 29, 2015, 09:32:48 pm »
Еще по ходу 5.1 - 1
http://v8.1c.ru/o7/201312opt/index.htm
Да, верно, упускаю мелочи (Web клиент)в вопросах..
« Последнее редактирование: Апрель 29, 2015, 09:40:43 pm от Droni »

Droni

  • Модератор
  • Пользователь
  • *****
  • Сообщений: 97
Re: Раздел 5. Производительность
« Ответ #8 : Апрель 29, 2015, 09:38:59 pm »
Аргументация предпочтительности динамического считывания данных например тут:
Спасибо. Тогда имхо остается один вариант 4.
Тут же (http://v8.1c.ru/o7/201312opt/index.htm) про динамический список:

Использование динамических списков

В версии платформы 8.2 появилась замечательная возможность писать произвольные запросы в динамических списках. И разработчики очень много пользуются этим в своих конфигурациях. Можно даже сказать, что злоупотребляют. Конечно, с одной стороны есть желание вывести в список как можно больше полезной информации, показать её пользователю. С другой стороны это желание приводит к тому, что появляются запросы, содержащие до 20 соединений с использованием вложенных запросов. Такой запрос, конечно, хорошо работать уже не будет. Почему он хорошо работать не будет? Потому что динамический список совсем не волшебный, и все запросы, которые он выполняет, при желании можно написать самостоятельно.

В своей работе динамический список использует курсорные запросы. Работать он может в трёх разных режимах и самый эффективный - это режим динамического считывания данных. При условии, что запрос приемлемый сам по себе, не перегружен соединениями и ограничениями на уровне записей и полей базы данных. В этом режиме динамический список считывает порцию данных, запоминает последнюю и первую строку. Если пользователь пролистывает список, то считывается следующая порция данных. С условиями, где значения полей сортировки больше предыдущих, или меньше предыдущих. В зависимости от того, вперёд или назад выполняется пролистывание.

Чтобы этот режим хорошо работал, для таблицы, из которой происходит выборка, должен быть индекс, и этот индекс должен подходить под условия отбора и порядка. Если используется отбор или сортировка по какому-то полю, то для него следует включить Индексирование с дополнительным упорядочиванием. Если в этом режиме подходящего индекса нет, то такой запрос "сваливается" в SCAN, и динамический список начинает работать очень медленно. И комфорт от использования такого списка будет очень низким. Поэтому запросы динамического списка нужно стараться составлять простыми.

Другой вариант работы динамического списка, когда динамическое считывание данных отключено, но задана основная таблица. Этот режим довольно редкий, используется он, например, в критериях отбора. По сути это тоже курсорная выборка, но по 1000 записей, которые хранятся в буфере на сервере. И клиент получает данные уже из буфера. Это менее эффективно, чем динамическое считывание.

И последний вариант работы, когда нет ни динамического считывания, ни основной таблицы. В этом режиме список начинает фактически целиком читать таблицу, накапливая её в буфере. Понятно, что эффективно это работать не будет.

st1llman

  • Пользователь
  • **
  • Сообщений: 26
  • ФИО: Дмитрий

Zheka

  • Пользователь
  • **
  • Сообщений: 13
Re: Раздел 5. Производительность
« Ответ #10 : Май 14, 2015, 04:10:10 pm »
С учебного тестирования с сайта http://dist.edu.1c.ru
5.4 - 1
5.6 - 3

Wonrims

  • Новичок
  • *
  • Сообщений: 8
Re: Раздел 5. Производительность
« Ответ #11 : Май 22, 2015, 07:47:17 pm »
У меня такие расхождения:
5.4 - 1
5.6 - 3
5.22 - 2 Статистика еще как учитывается