Прошу в ICQ 201216890 - обсудим.

посмотри еще эту тему
http://www.1cpp.ru/forum/YaBB.pl?num=1276610073

Пишите. Мне интересно.

У автора топика установлен SQL 2000 SP3.
После предварительного общения стало ясно что проблема заключается именно в перепроведении документов за период. Анализ замеров производительности показал что:
1) При проведении документа НЕ НА ТА действительно самым узким местом является расчет регистров при списании МПЗ.
2) При проведении документа НА ТА узким местом оказался модуль взаиморасчетов который проверял на наличие Налога с продаж в документе реализации. Так в цикле использовался вызов функции глНп... (не помню точно) ну и прочие моменты.
Был проведен анализ состояния фрагментации индексов и созданы планы обслуживания (job-ы).
По данным выводам было принято решение об оптимизации участка взаиморасчетов что и было сделано изменением кода.
После данных манипуляций стало ясно, что оптимизация путем перевода на прямые запросы принесет прирост порядка 20-30% при этом основная проблема замедления проведения на SQL 2000 решена не будет. В связи с высокой нагруженностью базы и сроками на реализацию оптимизации в пределах 8 часов было принято решение о выставлении приоритета на внедрение ReconnectNative при перепроведении документов. Была реализована обработка по перепроведению документов со сдвигом ТА в случае непроведения документа на следующий, изменен глобальный модуль для отсутствия курсоров.
Таким образом эффект достигнутый именно комплексом мероприятий по анализу и устранению узких мест привел к требуемому результату - перепроведению базы за время которое для этого отведено. Перевод на прямые запросы расчетов при проведении на ТА дадут в среднем от 20 до 30 % как выше и говорилось, но затраты на внедрение данного решения не соответствуют эффективности полученного результата на текущий момент.

(8) В переводе на русский в (7) сказано:
1. Поменяли код расчета взаиморасчетов. Полезно, но не совсем то.
2. Поставили в джобах дефрагментацию индексов. Это всегда полезно. Но опять не совсем то.
3. Использовали ReconnectNative. Вот теперь самое то.

Не знаю какой это ПУБ, но в Украинском точно сделано тормознуто, там регистры расчитвыются не один раз а построчно (когда то переделывал), можно начать искать в этом направлении.
2 - Посмотреть на таблицу остатков по регистрам, возможно остатки не закрываются и висят где то пересортицы, закрыть ненужные значения.
3 -  Быстрая обработка движений - добавляет в табицу движений регистра (RA) 2 поля "DATE_TIME_IDDOC" и "IDDOCDEF". Не думаю что при расчеие остатков эти поля необходимы
4 - Отбор движений - добавляет индекс к таблице движений по измерению
5 - Отбор итогов добавляет индекс в таблицу итогов по измерению

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

Ну и как вы сами понимаете индекс занимает место и замедляет запись, т.е. добавление индекса приведет к замедлению закписи в таблицы (что почти незаметно, но если в документе 100 строк и таки документов 1000 в день то разница уже будет заметна).

Neo писал(а) 14. Января 2011 :: 12:02:

Либо можно оптимизировать, либо остатки считаются неправильно, в зависимости от того, уникальны ли $Док.Товар в пределах документа.

Тогда агрегацию можно убрать.

Собственно в ПУБ действительно дурновато написан модуль проведения. Руки б за такое повыдергивать горе писателям. Но что есть то есть.
Если по уму то я переписываю (иногда полностью) модуль проведения для того что б можно было налету перепроводить базу. Делаю так:

Процедура ОбработкаПроведения()
    Если Константа.НашеПроведение=0 Тогда
	  // стандартное проведение
    Иначе
	  // наше перепроведение
    КонецЕсли;
КонецПроцедуры 

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

Флаг-функция ГрупповаяОбработка() видит только перепроведение, вызванное через Операции -> Проведение документов...

А оно не всегда бывает удобным.
Плюс, программно перепроведение вызывается из тучи мест - и всюду дописывать передачу параметра, чтоб вызывать перепроведение в нужном режиме?


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

Dmitry The Wing писал(а) 18. Января 2011 :: 01:57:

Да там каждый второй модуль проведения такой, что хоть вешайся.
Отчасти, это обусловлено тем, что первичный учет построен на регистрах; а по сформированным движениям пишутся проводки. Но только отчасти.

Согласен. Запись в таблицы документов идет. Специально немерял, но есть такое предположение что напрямую отрабатывать должно быстрей чем 1С методами. Хотя может и неправ, спорить небуду.

Да начиная с незабываемого

ЧтоСписывать = "000000100"; 

Ну и на примере документа Поступление из переработки:
например, такая строка:

СпособСписания = глСпособСписания(ВидМПЗ.Идентификатор(), ДатаДок);
Если (СпособСписания = 9) Тогда
	СтатусВозврата(0);
КонецЕсли; 

Это делается в цикле по строкам.
При этом, чуть выше (в этом же цикле) стоит куча проверок (заполненность реквизитов ТЧ документа) - и эта куча проверок завершается вполне логичным

Если ЕстьОшибкиЗаполнения = 1 Тогда
	Продолжить;
КонецЕсли; 

- чтоб просто показать ошибки по строкам, не гоняя тяжелые алгоритмы. (Хотя, на вскидку, мне помнится даже вариант с проверкой СтатусВозврата() = 0, вместо ЕстьОшибкиЗаполнения)

Хотя их вариант "ЕстьОшибкиЗаполнения" УЖЕ спорное решение. Мое мнение: уж лучше сделать лишний (отдельный) проход по строкам документа, в котором проверять заполненность (ну, может подготавливать какие дополнительные данные - какую-то ТЗ набить...).
Ибо такая простая вещь, как "автовод новой строки" в руках неопытного пользователя оборачивается документами с пустой последней строкой - и в стандартном ПУБе это означает, что мы по полной прогнали проведение, чтоб потом сказать "Ахтунг! строка незаполнена!!!!!".
И то, что по дефолту автоввод новой строки в ПУБе, может быть, и не включен - не отменяет порочности подхода.

Dmitry The Wing писал(а) 24. Января 2011 :: 06:19:

Ну, здесь косяк не в быстродействии, а в качестве кода.
Ибо каждый раз, когда я это вижу я, а) начинаю считать номера позиций; б) начинаю смотреть в глобале, а за что же отвечает каждая позиция.
Можно придумать несколько других схем передачи этого хитрого параметра, чтоб его можно было точно так же собирать в документе и парсить в глобале (например, банально через СписокЗначений.Установить("<ИмяРегистра>", 1)).

Цитата:

Ну, по хорошему, да - проверка заполнения реквизитов делается при записи.
А при проведении делается проверка остатков + подготовка таблицы партий для ФИФО (ЛИФО).
Но в ПУБе это все нах#рачено в модуль проведения.

А, вот еще вспомнил - далеко не всегда проводки создаются в единственном месте (как завершение ОбработкиПроведения()).
Например, глРасчетыПриПоступлении() сама формирует проводки

Написал получение остатков в модуле проведения расходной накладной прямым запросом. Если проведение идет задним числом, получается в разы быстрее. Но если проведение идет текущим временем (на ТА), то прямой запрос стабильно медленнее. Замеряю с помощью функции _GetPerformanceCounter(), при штатном расчете остатков (ОстаткиПолучить()) документ на 8 строк проводится где-то за 140-150 мс, при прямом запросе - за 160-180мс.

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

-------------------------------------------------------------------------------

ИТЗ=СоздатьОбъект("ИндексированнаяТаблица");
     
     Recordset.УстановитьТекстовыйПараметр("ТекДок",ТекущийДокумент());
     щийДокумент(),0));
     Recordset.УстановитьТекстовыйПараметр("перУслуга",перУслуга);
Recordset.УстановитьТекстовыйПараметр("Склад",Склад);
     
     Если ИтогиАктуальны()=1 Тогда
           ДатаРасч="";
     Иначе
           ДатаРасч=":ТекПоз~";
     КонецЕсли;
     
     Соед="
     |INNER JOIN $ДокументСтроки.РасходнаяНакладная as Д ON Д.IDDOC=:ТекДок AND Товар=$Д.Товар
     |";
     
     ДопСоединения="";
     ДопПоля="";
     
     Если ДокументОснование.Вид()="Счет" Тогда
           Recordset.УстановитьТекстовыйПараметр("ДокОсн",ДокументОснование);
           Recordset.УстановитьТекстовыйПараметр("ДокОснСклад",ДокументОснование.Склад);
           ДопСоединения=ДопСоединения+"
           |LEFT JOIN
           |$РегистрОстатки.РезервыТоваров("+ДатаРасч+","+Соед+",Товар=$Д.Товар AND Склад=:ДокОснСклад AND Счет=:ДокОсн~,(Товар),(Количество)) as РегРез ON $Док.Товар=РегРез.Товар";
           ДопПоля=ДопПоля+",
           |РегРез.КоличествоОстаток AS РезКол";
     КонецЕсли;
     
     //Общие остатки
     ДопСоединения=ДопСоединения+"
     |LEFT JOIN
     личество)) as Рег1 ON $Док.Товар=Рег1.Товар";
     ДопПоля=ДопПоля+",
     |Рег1.КоличествоОстаток AS ОбщКол";

     //Общий путь
     ДопСоединения=ДопСоединения+"
     |LEFT JOIN
     оличество)) as РегП ON $Док.Товар=РегП.Товар";
     ДопПоля=ДопПоля+",
     |РегП.КоличествоОстаток AS ОбщПуть";

     //Общие резервы
     ДопСоединения=ДопСоединения+"
     |LEFT JOIN
     личество)) as РегРез1 ON $Док.Товар=РегРез1.Товар";
     ДопПоля=ДопПоля+",
     |РегРез1.КоличествоОстаток AS ОбщРезКол";
     
***

     ТекстЗапроса="
     |SELECT
     |$Док.Товар as [Товар $Справочник.Товары],
     |$Док.Количество as [Кол],
     |Рег.КоличествоОстаток as [Ост],
     |РегПарт.КоличествоОстаток AS СебестКол,
     |РегПарт.СуммаУпрОстаток AS СебестУпр,
     |РегПарт.СуммаРубОстаток AS СебестРуб"
     +ДопПоля+"
     |FROM
     |$ДокументСтроки.РасходнаяНакладная as Док
     |LEFT JOIN
     |$Справочник.Товары as СпрТов ON $Док.Товар=СпрТов.ID
     |LEFT JOIN
     |$РегистрОстатки.ОстаткиТоваров("+ДатаРасч+","+Соед+",Товар=$Д.Товар AND Склад=:Склад,(Товар),(Количество)) as Рег ON $Док.Товар=Рег.Товар
     |LEFT JOIN
     ичество,СуммаУпр,СуммаРуб)) as РегПарт ON $Док.Товар=РегПарт.Товар"
     +ДопСоединения+"
     |WHERE
     |Док.IDDOC=:ТекДок AND $СпрТов.ВидТовара<>:перУслуга
     |";
     
     RecordSet.ВыполнитьИнструкцию(ТекстЗапроса, ИТЗ);
     
     Если КонстРазрОтрицОст=Перечисление.Булево.Нет Тогда
           ИТЗ.ВыбратьСтроки();
           Пока ИТЗ.ПолучитьСтроку()=1 Цикл
                 Если ИТЗ.Кол>ИТЗ.Ост Тогда
                       Сообщить("На складе нет товара "+ИТЗ.Товар+". Не смог провести!");
                       СтатусВозврата(0);
                       Возврат;
                 КонецЕсли;
           КонецЦикла;
     КонецЕсли;
     
     ИТЗ.ДобавитьИндекс("ИндТовар","Товар",0);

     ВыбратьСтроки();
     Пока ПолучитьСтроку()=1 Цикл
           Если ИТЗ.НайтиСтроку("ИндТовар",Товар,0,1)>0 Тогда
                 
           КонецЕсли;
     КонецЦикла;

Имеешь в виду, что лучше не получать табличную часть запросом и потом джойнить регистры, а сразу запрос к регистру по списку товаров табличной части? Так будет быстрее?

Просто в учебнике по 1СРР именно такая методика приведена (да и 1СV8 тоже вроде), вот и взял ее за основу. Интересно услышать, кто еще как у себя реализовывал на практике, и насколько но получается быстрее или медленнее в итоге...

и еще полезно включить:
RecordSet.ОбратныйРасчетОтТА(1)

Цитата:


При получении остатков на ТА наверное это не актуально. В моем случае расходная проводится в 99% процентов случаев после ТА.

+ у тебя лишнее условие в виртуальной табличке на товар.. ибо ты унутри ВТ и так присоединяешь строки документа по иннеру + on товар в ВТ = товар в тч дока.

Как лучше объединять данные из нескольких регистров: джоинами или юнионами?

Задача все та же, получение остатков в модуле проведения. Роль играют даже доли секунды, хочется по максимум ускорить.

Например, получаю я остатки из регистра ОстаткиТоваров по списку товаров из ТЧ. Но надо еще получить стоимость. Что будет лучше: приджойнить по полю товар или опять же сделать запрос по списку товаров из ТЧ и объединить юнионом?

Neo писал(а) 09. Февраля 2011 :: 08:51:

Что-то мне подсказывает что быстрее джойн отработает. Сделай так и так и замерь скорость.

Вариант с джоинами:


ИТЗ=СоздатьОбъект("ИндексированнаяТаблица");
           щийДокумент(),0));
     Recordset.УстановитьТекстовыйПараметр("перУслуга",перУслуга);
     Recordset.УстановитьТекстовыйПараметр("Склад",Склад);
     Recordset.УложитьСписокОбъектов(СписокТоваров,"#СписокТоваров","Товары");
     
     Если ИтогиАктуальны()=1 Тогда
           ДатаРасч="";
     Иначе
           ДатаРасч=":ТекПоз~";
     КонецЕсли;
     
     ФильтрПоТовару="Товар IN (SELECT Val FROM #СписокТоваров)";
     
     ДопСоединения="";
     ДопПоля="";
     
     Если ДокументОснование.Вид()="Счет" Тогда
           Recordset.УстановитьТекстовыйПараметр("ДокОсн",ДокументОснование);
           Recordset.УстановитьТекстовыйПараметр("ДокОснСклад",ДокументОснование.Склад);
           ДопСоединения=ДопСоединения+"
           |LEFT JOIN
           |$РегистрОстатки.РезервыТоваров("+ДатаРасч+",,"+ФильтрПоТовару+" AND Склад=:ДокОснСклад AND Счет=:ДокОсн~,(Товар),(Количество)) as РегРез ON Рег.Товар=РегРез.Товар";
           ДопПоля=ДопПоля+",
           |РегРез.КоличествоОстаток AS РезКол";
     КонецЕсли;
     
     Если фАктуальность=1 Тогда
           //Общие остатки
           ДопСоединения=ДопСоединения+"
           |LEFT JOIN
           ство)) as Рег1 ON Рег.Товар=Рег1.Товар";
           ДопПоля=ДопПоля+",
           |Рег1.КоличествоОстаток AS ОбщКол";
           //Общий путь
           ДопСоединения=ДопСоединения+"
           |LEFT JOIN
           ество)) as РегП ON Рег.Товар=РегП.Товар";
           ДопПоля=ДопПоля+",
           |РегП.КоличествоОстаток AS ОбщПуть";
           //Общие резервы
           ДопСоединения=ДопСоединения+"
           |LEFT JOIN
           ство)) as РегРез1 ON Рег.Товар=РегРез1.Товар";
           ДопПоля=ДопПоля+",
           |РегРез1.КоличествоОстаток AS ОбщРезКол";
     КонецЕсли;
     
*** *** ***

     ТекстЗапроса="
     |SELECT
     |Рег.Товар as [Товар $Справочник.Товары],
     |Рег.КоличествоОстаток as [Ост],
     |РегПарт.КоличествоОстаток AS СебестКол,
     |РегПарт.СуммаУпрОстаток AS СебестУпр,
     |РегПарт.СуммаРубОстаток AS СебестРуб"
     +ДопПоля+"
     |FROM
     |$РегистрОстатки.ОстаткиТоваров("+ДатаРасч+",,"+ФильтрПоТовару+" AND Склад=:Склад,(Товар),(Количество)) as Рег
     |LEFT JOIN
     тво,СуммаУпр,СуммаРуб)) as РегПарт ON Рег.Товар=РегПарт.Товар
     |LEFT JOIN
     |$Справочник.Товары as СпрТов ON Рег.Товар=СпрТов.ID"
     +ДопСоединения+"
     |WHERE
     |$СпрТов.ВидТовара<>:перУслуга
     |";
     
     RecordSet.ВыполнитьИнструкцию(ТекстЗапроса, ИТЗ);

По Джойнам:

1) убери ФильтрПоТоварам из каждого запроса по регистрам, которые цепляешь через Left Join.
Скуль сам разберется, как ему оптимизировать эти (ведомые) выборки, глядя на результат ведущей выборки.

2) Попробуй вместо
ФильтрПоТовару="Товар IN (SELECT Val FROM #СписокТоваров)";
сделать так:
ФильтрПоТовару="Товар IN (SELECT $ДокТЧ.Товар From $ДокументСтроки.Реализация ДокТЧ (Nolock) Where IDDoc = :идТекДок)";
где идТекДок - это, есно, ссылка на проводимый документ (ну и вид дока скорректируй, при необходимости)

---

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

Вообще, по моим наблюдениям, когда встречаются по сути дублирующие условия внутри ВТ и вовне (например, при JOIN ON), то это не снижает скорость. А если убрать условие из ВТ, то замедление наблюдается...

Ну, чем в (45) стало побыстрее, но все равно медленнее гораздо, чем штатное получение остатков с помощью ОстаткиПолучить()...

Neo писал(а) 10. Февраля 2011 :: 10:38:


1 а ты считаешь время вместе с расчетом регистра?
2 что ты вообше хочешь получить? причем здесь партии, товары в пути и прочее...
3 не проще поститать все отдельно, а потом слить в одну таблицу или следать на подзапросах?

А можешь целиком кинуть модуль проведения документа? (лучше в видет аттача текстового файла)?