|
v7: Замер производительности запроса | ☑ | ||
---|---|---|---|---|
0
pofigos
24.10.13
✎
11:12
|
Доброе утро...
Скажу честно. ни разу не пользовался и не задавался вопросом. Подскажите\расскажите\покажите, как можно сравнить скорость выполнения запроса (штатного и прямого) до тысячных секунды желательно... Спасибо заранее |
|||
1
Андрей_Андреич
naïve
24.10.13
✎
11:13
|
Запустить тысячу раз и измерить до секунды :)
|
|||
2
Злой Бобр
24.10.13
✎
11:15
|
(0) Отладчиком воспользоваться.
|
|||
3
varelchik
24.10.13
✎
11:16
|
_GetPerformanceCounter();
тебе поможет. |
|||
4
Злой Бобр
24.10.13
✎
11:17
|
+2 Еще тупой вариант вставить кусок кода в начало и конец:
Сообщить("Начало "+ТекущееВремя()); Сообщить("Конец "+ТекущееВремя()); |
|||
5
pofigos
24.10.13
✎
11:19
|
(4)Текущее время, на сколько я знаю до секунд... если у меня запрос выполняется доли секунды. нужно знать это время... Так же замерять и штатный запрос...
|
|||
6
varelchik
24.10.13
✎
11:19
|
(0) вот только на счет тысячных ты погорячился.
При правильно написанном прямом запросе разница будет в разы. |
|||
7
pofigos
24.10.13
✎
11:35
|
(6) В том то и дело... один и тот же запрос переписал на прямой... при выполнении даже невооруженным взглядом видно, что скорость выше на порядок... Ну хотелось бы знать точное время выполнения.
|
|||
8
dk
24.10.13
✎
11:40
|
имхо измерять время в тысячных глупо - слишком велика погрешность
либо несколько запросов в цикле, либо запрос на большем объеме данных тестировать про _getperfomancecounter уже написали |
|||
9
pofigos
24.10.13
✎
11:42
|
(3) Спасибо, то что доктор прописал ))
(8) Естественно для замеров будет делаться запрос в цикле и вычисляться среднее. Так же спасибо за функцию. На счет объема данных не думал, но мысль хорошая.. развернуться есть где :) Всем спасибо |
|||
10
varelchik
24.10.13
✎
12:30
|
(9)и еще если делаешь запросы за период, не советую использовать при выполнении подряд один и тот же период.
Потому как SQL кеширует результат запроса. |
|||
11
Злой Бобр
24.10.13
✎
15:54
|
(5) Ну и кому нужны твои тысячные? Потратить день и увеличить скорость на 0,001 ? Да за такое нада пальцы в двери, а еще лучше что б и не плодились.
Любые потуги которые в результате дают меньше 10% прироста - яйца выеденного нестоят. |
|||
12
varelchik
24.10.13
✎
17:01
|
(11) верное замечание.
Вот я промучался с переводом расчетов на прямые запросы в модулях проведения. Да времени ушло немало. НО! время проведения сократилось в 10 раз! |
|||
13
PRO100 NigGaZ
24.10.13
✎
18:09
|
потрясающий результат! я переписал только модуль проведения заявки покупателя, получились интересные результаты :) при проведении задним числом быстрее в 5-8 раз, собственно по ТА такой же результат :)
|
|||
14
mikecool
24.10.13
✎
18:18
|
(7) на порядок это мало, или прямой запрос не очень оптимален, или у них планы почти одинаковые
|
|||
15
PRO100 NigGaZ
24.10.13
✎
18:38
|
попробуй использовать данный код:
в глобальном модуле
и по мере выполнения кода
|
|||
16
PRO100 NigGaZ
24.10.13
✎
19:02
|
и результат будет примерно такой
Документы провелись за: 0/00:18:28.201 |
|||
17
PRO100 NigGaZ
24.10.13
✎
19:13
|
я просто слышал что отладчик время считает от тактовой частоты процессора, и время выполнения общее в отладчике никогда не совпадало с реальным, у меня по крайней мере...
Перенос ТА на нужную дату за: 0/00:00:26.595 Значения периодических реквизитов удалены за: 0/00:01:23.948 Документы помечены на удаление: 0/00:00:00.000 Документы ввода начальных остатков введены за: 0/00:01:24.066 Перенос ТА на нужную дату за: 0/00:00:09.500 Помечаем на удаление найденных контрагентов и подчиненные справочники: 0/00:00:13.712 Поиск и пометка на удаление неактивнх товаров: 0/00:00:02.976 Удаляем движения регистров: 0/00:00:00.536 Делаем документы непроведенными: 0/00:01:44.364 Все движения регистров удалены. Вся лишняя информация помечена на удаление за: 0/00:02:01.589 Перенос ТА на нужную дату за: 0/00:00:01.383 Проведение документов ввода начальных остатков: 0/00:01:45.360 Общее время выполнения: 0/00:07:12.441 |
|||
18
pofigos
25.10.13
✎
11:42
|
(11) Откуда столько ненависти то.... я хочу видеть прирост производительности в целом... Запрос за 1 день даст результат один, за год уже совсем другой... а если 20 пользователей сразу запустят каждый свою отчетность... так вот мне и нужно знать. стоит это того, чтобы переводить на прямые или нет.
А любые потуги.. Хм, не знаешь на каком проекте сижу и что делаю, не нужно делать выводы... И видимо перед тем. как браться и делать, я хочу видеть, чтоб это стоило того. А если брать в целом задачу, на данный момент это оптимизация базы в целом. Тут косяков и г*** столько, что не перечесть... Так вот вопрос к тебе, Бобрик.. если все равно буду менять процедуры и модули, так почему не переписать на прямой и затратить на него, путь даже 1 час.. А лучше всего, если в кучи документах одинаковые процедуры, не вынести в глобальник и кинуть на нормальный запрос? И да. я не из тех людей. которые кинуть задачу и будут сидеть нихрена не делать.. как минимум практика в написании запросов и вообще оптимизации кода никому никогда не мешает. |
|||
19
PRO100 NigGaZ
25.10.13
✎
14:51
|
не парься, думаю оно того стоит, выше пример свертки базы делал очень долго, стандартная работала неделю! на прямых запросах и измененным алгоритмом как видишь 7 минут (4-7 минут)
|
|||
20
Salimbek
25.10.13
✎
15:02
|
(18) Если реально хочешь "если в кучи документах одинаковые процедуры, не вынести в глобальник и кинуть на нормальный запрос", то посмотри заодно и в сторону классов 1С++, ими пользоваться (и допиливать на ходу) удобнее, чем глобальником.
|
|||
21
varelchik
25.10.13
✎
15:39
|
(20) во во!
|
|||
22
Злой Бобр
26.10.13
✎
16:17
|
(18) При нормальной скульной железке особой разницы нету - запустит 1 пользователь или 20. Расхождение будет не больше 10%. Поэтому если есть мнение что ускорив запрос на 1% при одновременном запуске 20 пользователями получим ускорение в 10% - это ошибочное мнение.
Пользуйся отладчиком, там посмотри замер и оптимизируй начиная с максимального времени выполнения. Просто пытаться оптимизировать кусок кода который занимает 5% и пропускать код который занимает 30+ процентов - немного для меня непонятно. Ну это образно говоря. Теперь что касается вопроса. Все прекрасно знают узкие места типовых. И да, часть из них сидит в глобальнике. Можно конечно пытаться оптимизировать, но максимальное ускорение будет только когда в проведение будет выдаваться уже готовое значение а не рассчитываться в модуле. Поэтому лучше пойти по этому пути, а не тратить время и всеравно придти к этому пониманию. Ну и незабываем что конфигурация должна одинаково работать как в дбф так и в скульном вариантах. Поэтому переписывать все под скуль и забить на дбф - это наступать на грабли. |
|||
23
pofigos
28.10.13
✎
19:57
|
(22) На самом деле тема вопроса подразумевает образный подход к базе... Задачу, которую себе поставил - оптимизация в целом.. Если для типовых более менее понятно в каких местах копать, то в самописной это жестоко...
Идея как таковая собирать данные по работе пользователей. Во-первых будет информация чем же все-таки они пользуются и что в первую очередь надо просматривать... что из этого у них занимает больше времени... Часть запросов перепишу на прямые, т.к. уже по тестам видно, что криво написаны... Более того покажется глупой эта работа, но буквально через год перейдем на 8-ку. В связи с этим ДБФ вариант не рассматриваю.. да и при таком документообороте dbf база через месяц достигнет максимума. На счет готового значения в модуле полностью соглашусь... Очень не понятно, для чего в модуле проведения куча рассчетов с записью значений в справочники и созданием документов... ну и как следствие транзакции наш очень частый гость. В принципе тему можно закрыть. на свой вопрос я ответ получил..буду применять на практике задуманное. Всем спасибо. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |