|
Внешняя компонента: какой прок? | ☑ | ||
---|---|---|---|---|
0
Игорь_МММ
15.03.18
✎
12:33
|
Спрашиваю совета у знающих людей:
есть запрос, который в цикле выполняется 100500 раз, соответственно им определяется производительность кода. Все что можно выжать из 1С, думаю, уже выжал. Стоит ли думать в сторону написания внешней компоненты для увеличения производительности? Может ли это существенно (кратно) изменить ситуацию? |
|||
1
Tatitutu
15.03.18
✎
12:34
|
Может это слабое место
"есть запрос, который в цикле выполняется 100500 раз" |
|||
2
Beduin
15.03.18
✎
12:34
|
(0) В цикле запросы это очень неправильно
|
|||
3
Игорь_МММ
15.03.18
✎
12:36
|
(1)(2) расчет производственных графиков - по другому никак.
|
|||
4
Beduin
15.03.18
✎
12:38
|
(3) Кидай кусок кода
|
|||
5
timurhv
15.03.18
✎
12:39
|
(4) Там же адский алгоритм скорее всего
|
|||
6
Малыш Джон
15.03.18
✎
12:40
|
Круть! Онлайн отладка кода!
|
|||
7
timurhv
15.03.18
✎
12:42
|
(0) Самописка или типовое решение?
|
|||
8
Игорь_МММ
15.03.18
✎
12:43
|
(4) слушай, не хочется этим заморачиваться - уже давал на оптимизацию, смотрели и сам код и данные - думаю пройденный этап.
(7) самописная |
|||
9
Бертыш
15.03.18
✎
12:46
|
(0) Смотря что Вы хотите от внешней компоненты и как Вы её будете делать
|
|||
10
FIXXXL
15.03.18
✎
12:46
|
(3) избыточное хранение + расчет(подготовка данных) регламентами в несколько потоков?
|
|||
11
DmitriyDI
15.03.18
✎
12:48
|
получить данные в таблицы проиндексировать и брать данные из них в цикле
|
|||
12
timurhv
15.03.18
✎
12:48
|
(8) План запроса гляньте на SQL!
Это если не менять алгоритм, структуру хранения и тд. |
|||
13
ДемонМаксвелла
15.03.18
✎
12:52
|
(0) и всё-таки рассмотрите вариант сделать один запрос и получить все необходимые данные один раз. И вместо запроса можно искать в индексированной таблице значений нужные строки, это будет намного быстрее.
|
|||
14
Игорь_МММ
15.03.18
✎
12:52
|
(9) увеличения скорости работы кода
(10) думал об этом .. разбивать придется запрос, а он сам по себе не так долог - время теряется на том, что он повторяется очень много раз - реально порядка 500-700раз. Будет ли толк? время будет тратиться на стыковку данных потоков ... (11) (12) да, это понятно |
|||
15
VladZ
15.03.18
✎
12:53
|
Что там такого нужного делается 500 раз?
|
|||
16
Вафель
15.03.18
✎
12:54
|
(14) может 1 раз данные получить и уже по тз индексирвоанной искать?
|
|||
17
spectre1978
15.03.18
✎
12:54
|
(3) компонентой вы запросы существенно не ускорите. Компонентой можно ускорить расчеты, убрав математику со скриптового языка в машинный код. А SQL все равно будет выполняться на сервере что так, что этак.
|
|||
18
VladZ
15.03.18
✎
12:54
|
Сдается мне, алгоритм заложен неоптимальный.
|
|||
19
Вафель
15.03.18
✎
12:54
|
(15) скорее всего разворачивание узлов
|
|||
20
Вафель
15.03.18
✎
12:55
|
можно также посмотреть в сторону параллельного разворачивани яэтих самых узлов
|
|||
21
Игорь_МММ
15.03.18
✎
12:55
|
(13) один запрос - никак, последующие данные базируются на результатах выполнения предыдущей итерации. Каждую итерацию исходные данные меняются.
(17) спс |
|||
22
spectre1978
15.03.18
✎
12:56
|
(8), (21) Если оптимизация ничего не дает - тогда нужно переделывать структуру БД таким образом, чтобы не было множества запросов, и затем осуществить перенос данных из старых объектов в новые.
|
|||
23
Игорь_МММ
15.03.18
✎
12:58
|
(22) уже смотрели. множество запросов обусловлено самой решаемой задачей - нельзя получить исходных данных для последующего состояния, не отработав текущее.
|
|||
24
Малыш Джон
15.03.18
✎
12:58
|
(21) А генерация текста запроса в зависимости от ситуации не поможет?
|
|||
25
spectre1978
15.03.18
✎
12:58
|
либо по крайней мере переделать структуру БД так, чтобы вот эти внутрициклические запросы были наилегчайшими и выполнялись крайне непродолжительное время. Еще вариант оптимизации - всосать все что нужно в ТЗ и выполнять вычисления вообще без запросов.
|
|||
26
spectre1978
15.03.18
✎
12:59
|
(23) см. (25)
|
|||
27
Вафель
15.03.18
✎
13:03
|
Кстати можно перед выполнением попытаться прогреть кэш
|
|||
28
Игорь_МММ
15.03.18
✎
13:04
|
(24) да текст все время один и тот же - нужно отрабатывать одни и те же данные, но в измененном виде на каждую итерацию (измененные предыдущим шагом)
(25) там много соединений таблиц - в итоге ТЗ будет, думаю, с 6-тью нулями. Запрос по ходу соединений, фильтрует сразу, то что не подходит, а тут табличка будет ой-ой |
|||
29
ДемонМаксвелла
15.03.18
✎
13:08
|
(0) индексы в таблицах бд все сделаны, которые нужны?
|
|||
30
Игорь_МММ
15.03.18
✎
13:10
|
(27) это что за тема - как делается?
(29) да |
|||
31
Малыш Джон
15.03.18
✎
13:20
|
(28) "нужно отрабатывать одни и те же данные, но в измененном виде на каждую итерацию (измененные предыдущим шагом) "
т.е. делаем запрос, обрабатываем данные, вносим данные в базу, делаем запрос и т.д.? а если: делаем запрос, выгружаем в тз, обрабатываем данные, вносим данные в базу, вносим соответствующие изменения в ТЗ - и ничего не надо читать? |
|||
32
Малыш Джон
15.03.18
✎
13:21
|
+(31) ничего не надо читать - это, в смысле, не надо делать ещё один запрос к измененным данным, т.к. они уже есть в ТЗ
|
|||
33
Игорь_МММ
15.03.18
✎
13:26
|
(31) (32) запрос выдает результат, на основании которого меняются данные, не в базе, конечно,а в соответствующих ТЗ - эти ТЗ и есть исходники для запроса, там они обрабатываются и выдается новый рез-тат и тд. В итоге формируется целевая табличка, которая и пишется в базу при accept пользователя
|
|||
34
ilya_i
15.03.18
✎
13:39
|
Позовите математика, может он вам другой алгоритм решения придумает.
|
|||
35
al_zzz
15.03.18
✎
14:01
|
(0) Не на Мавроди, случайно, работаете?
|
|||
36
Малыш Джон
15.03.18
✎
14:18
|
(33) т.е запрос не к базе, а к ТЗ идет в цикле?
|
|||
37
Dmitry1c
15.03.18
✎
14:24
|
(0) генетические алгоритмы - посмотри, можно ли их применить к твоей задаче.
|
|||
38
arsik
гуру
15.03.18
✎
14:29
|
(33) Зачем вообще в тз сохранять? Есть же временные таблицы.
Ну сгененрируйте сначала 1 запрос и выполните 1 раз. |
|||
39
Вафель
15.03.18
✎
14:29
|
(37) может тогда сразу нейронные сети?
|
|||
40
arsik
гуру
15.03.18
✎
14:31
|
(38) Неправильно выразился. Сделайте длинный состоящий из 500 запросов.
Кстати какие ограничения сейчас у пакетного запроса? |
|||
41
Timon1405
15.03.18
✎
14:31
|
выполнить запрос несколько раз чтобы закэшировался его(предполагается что оптимальный) план.
имеет смысл если во всех 500 запросах как минимум одинаковый текст(на скуле), если же текст запроса меняется от раза к разу, то смысла не имеет |
|||
42
Timon1405
15.03.18
✎
14:32
|
(41) к (30)
|
|||
43
Timon1405
15.03.18
✎
14:33
|
(40) не прокатит, следующий запрос должен использовать результат работы прошлых
|
|||
44
DmitriyDI
15.03.18
✎
14:35
|
забить раз так все сложно и выполнять ночью регламентным заданием
|
|||
45
Кирпич
15.03.18
✎
14:36
|
(43) А предыдущие запросы данные в БД меняют?
|
|||
46
Скользящий
15.03.18
✎
14:37
|
(44) Еще вариант выполнять в копии базы где никто не работает.
|
|||
47
arsik
гуру
15.03.18
✎
14:38
|
(43) Ты издеваешься что ли?
ВЫБРАТЬ ТЗ.Показатель ПОМЕСТИТЬ втТЗ ИЗ &ТЗ КАК ТЗ ; //////////////////////////////////////////////////////////////////////////////// ВЫБРАТЬ втТЗ.Показатель ПОМЕСТИТЬ втТЗ1 ИЗ втТЗ КАК втТЗ ; //////////////////////////////////////////////////////////////////////////////// УНИЧТОЖИТЬ втТЗ ; //////////////////////////////////////////////////////////////////////////////// ВЫБРАТЬ втТЗ1.Показатель ПОМЕСТИТЬ втТЗ ИЗ втТЗ1 КАК втТЗ1 ; //////////////////////////////////////////////////////////////////////////////// УНИЧТОЖИТЬ втТЗ1 ; //////////////////////////////////////////////////////////////////////////////// ВЫБРАТЬ втТЗ.Показатель ПОМЕСТИТЬ втТЗ1 ИЗ втТЗ КАК втТЗ |
|||
48
timurhv
15.03.18
✎
14:42
|
(47) Имеется ввиду: запрос - запись в БД - запрос - запись в БД и тд
|
|||
49
arsik
гуру
15.03.18
✎
14:44
|
(48) Нигде такого не написано. У него же написано, что результат предыдущего запроса выгружается в ТЗ и эта ТЗ используется в следующем. А пишется только результат последнего.
|
|||
50
Вафель
15.03.18
✎
14:52
|
все эти пляски с запросом не помогут, тк алгоритм рекурсивный
|
|||
51
mingw
15.03.18
✎
14:57
|
(50) Дело не в алгоритме. В незнании ничего. Кроме запросов.
|
|||
52
arsik
гуру
15.03.18
✎
14:58
|
(50) Можно просто рассчитать примерное количество рекурсий. И например разбить на 5 запросов по 100.
И сделать 5 основных циклов плюс все остальные уже отдельно, по старому. |
|||
53
mingw
15.03.18
✎
14:58
|
Обрабатывать ТЗ запросами - редкостный изврат.
|
|||
54
Вафель
15.03.18
✎
15:00
|
(52) Ну попробуй сгрупрпируй запросы для алгоритма разузлования
|
|||
55
dmpl
15.03.18
✎
15:01
|
(14) Когда все способы оптимизации использованы, и все равно медленно - надо использовать алгоритмическую оптимизацию.
|
|||
56
Sserj
15.03.18
✎
15:10
|
(0) Вообще сложно размышлять о виртуальных запросах не видя чего же там именно нужно получать.
Но если он у тебя таки один и тот же базируется на результатах предыдущего, то внешняя компонента, или даже не компонента а просто прямой запрос к SQL тебе даст то чего нет в запросах 1С - Common Table Expressions. Если их понимаешь, то вполне возможно получишь очень ощутимый прирост. |
|||
57
arsik
гуру
15.03.18
✎
15:38
|
(54) Если я правильно понял, то вот простейший пример разузлования.
|
|||
58
Вафель
15.03.18
✎
15:39
|
(57) И что разворачивает любую вложенность уровней?
|
|||
59
arsik
гуру
15.03.18
✎
15:42
|
(58) Здесь 3. Но я же сказал. Нужно сделать 1 запрос состоящий из 500. Но выполнить 1 раз.
После этого посмотреть если еще остались не разузлованные, тогда еще. |
|||
60
arsik
гуру
15.03.18
✎
15:44
|
+ (59) Это будет быстрее, чем 500 запросов в цикле
|
|||
61
Малыш Джон
15.03.18
✎
15:44
|
(59) прочитай (28)
|
|||
62
arsik
гуру
15.03.18
✎
15:48
|
(61) И? Он делает то же самое, но просто из запроса выгружает в ТЗ, а потом обратно тз загоняет в запрос. Я предлагаю просто вместо ТЗ воспользоватся временной таблицей скуля.
Ну выход из итерации у него проверяется после каждого запроса. В моем случае это и не надо. Ну подумаешь пару десятков раз лишних крутанется. Но выигрыш будет. |
|||
63
Игорь_МММ
15.03.18
✎
15:54
|
(36) да
(37) что-то типа этого и происходит (38) тоже пробовал - врем таблицы надо убивать после использования - выигрыша во времени не получилось (48) (49) см. (33) (56) спс, посмотрю |
|||
64
Малыш Джон
15.03.18
✎
15:54
|
(62) ты не то прочитал. Между запросами ТЗ обрабатывается и не нужное отбрасывается, иначе в конце, после всех соединений получится монструозная ТЗ. Ты предлагаешь прямо в запросе все соединения делать. У тебя именно это и получается - охрененная ТЗ.
|
|||
65
Игорь_МММ
15.03.18
✎
15:57
|
(53) не можно по другому - реально. задача не позволяет рассматривать каждую таблицу отдельно - только в компоте
|
|||
66
arsik
гуру
15.03.18
✎
15:59
|
(64) Ну отбрасывать можно и запросом. Допустим те которые уже не разузловываются скидывать в отдельную временную таблицу.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |