Где хранится таблица значений? #755519

Добрый день! Подскажите пожалуйста где физически во время обработки хранится Таблица значений в клиент-серверном варианте. На сервере базы данных или на сервере 1С:Предприятия?  В оперативной памяти, кэше или еще где-то? Не могу найти информацию по этому поводу.

в памяти

В памяти сервера 1С?

Правильный ответ: там! :)

На серевере, в озу. если квота вышла то на харде в темпах.

Если про реквизит Формы. То на клиенте. Если про то, что обрабатывается по директиве "&НаСервере", то все перемещается на Сервер и обрабатывается на сервере :) Вообще все это как-то не оптимально, реализовано. Почему нельзя объявить реквизиты формы, которые не надо перемещать на сервер. Или делать это выборочно, по списку :)

а что, уже нельзя?

На клиенте не хранится ТЗ. Там есть сериализованных данных.

И на клиенте вообще ничего не хранится, это, по сути, браузер.

Теоретически я так и думала, а вот практически при выполнении кода две конфигурации, расположенные на разных серверах БД, но исполняемые на одном сервере 1С дают разное время код (упрощенно) Данные абсолютно одинаковые

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

И щито?

Кстати, нафига запрос в ТЗ выгружать? 1С всячески  рекомендует выборку юзать.

ОК попробую Это дает лучшую производительность?

Естественно. Выборка порционна. Обычно за такой код увольняют.

А почему бы и нет? Удобно вполне. Можно курсор юзать по индексу. Щас-то уже не 640 кб ОЗУ на дворе.

Фигня это. За это не увольняют, а снижают балл на экзамене по платформе.

А почему?! Коллеги, когда у вас в выборке 20 строк - то пофиг. Когда 20млн - тогда глаза открываются.

ТЗ из запроса = созданию второго (дубля) объекта, не сериализуемого в памяти на сервере. При том, что он уже есть и вполне себе сериализуем.

Полностью согласна, но мне нужно было четко разделить время обращения к БД и исполнения на сервере. Насчет выборки была не уверена, а ТЗ всегда думала что хранится на сервере 1С.

Поэтому результат и удивил

Причём тут код в и ТЗ на сервере 1с?

ТЗ на клиенте нет. В принципе.

ТЗ=Запрос.Выполнить.Выгрузить; Выгружает результат запроса в таблицу значений

Ну и чо? Две базы на разных серверах СУБД. Код на сервере 1с.

Груви сказал - ТЗ хранится на сервере 1с в ОЗУ, всё.

Откуда такие вопросы вообще в ? Прям озадачилась. Биты в памяти менять через ассемблер собралась что ли

Не все. Может упасть на хард.

Ну, файл подкачки тоже ОЗУ

Нужно сравнить производительность 2 серверов БД. Код слегка переукоротила было примерно вот так: Изначально предполагалось что времяЗапроса будет отличаться, а времяОбработки останется примерно одинаковым, а вот вышло наоборот. Не могу понять почему

И где тут обработка?

В коде все делается на сервере, копируется массив данных, непонятно зачем, и перебирается по индексированному полю. В принципе тормозить должно.

*31 по индекированному

Производительность двух серверов БД - окей... Делаешь одну обработку и гоняешь её на две базы, что и делаешь

То бишь запрос у неё одинаково работает, а итерация по ТЗ не одинаково. И она подозревает, что ТЗ хранится в памяти сервера БД

А количество строк в ТЗ одинаковое?

Какие все подозрительные. Не проще ли посмотреть, что сервер получает и как хранит?

эххх, поколение пепси.

их бы запустить поработать с ASP.NET глаза бы открылись на мир...

Без разницы тут. Просто УИД

А чо там? Я работал в 2008 г. Чото крутое?

позволяет понять возможности клиента и сервера, что можно и что нельзя. а то все 1С плохое...

Для такого кода запрос не нужен, достаточно Справочники.ВнутренниеДокументы.Выбрать;

ой-ли. А зачем же позвольте вас спросить гуру мы кеши всякие чистим??

Вполне кошерно выгружать запрос в тз. Ведь вы же максимально фильтруете его и на выходе у нас пара сотня строк, не больше. Не так ли Грувви?

Человек смотрит 1) скорость выполнение кастериндексскана 2) перебор тз Как варик пишет обоснование увеличения опреративы. Типо бла бла добавите 10 гигов и вот этот код начнет выполнятся быстрее.

Пара сотня не критична, миллионы критично

10 млн доков / 365 дней = 27 доков в день

еще раз. Миллионов у вас не должно быть. Никогда.

Еще очень кошерно делать выборку для заполнения тч документа, и не в коем случаи не пользоваться ЗаполнитьЗначенияСвойств. Ибо тру 1сники зп получают от времени и количества строчек кода.

*27 тыщ в день

Почему? А если обмен?

У меня тут СП завалялось какое-то. Оттуда: ... Доступность: Сервер, толстый клиент, внешнее соединение. ..." Так что не совсем верно. При работе в обычных формах ТЗ нормально живёт на клиенте.

Причём тут обмен?

Когда у вас в выборке 20 млн строк - то само её существование говорит о том, что запрос написан неверно)

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

Ложь

ни когда не говори ни когда

+100500 Поражают крайне критические выводы

вообще. автор занимается хернёй.

Автор, ответ на твой вопрос: На сервере mssql между тестами

Компиляция прям для клиента?

порционные запросы в цикле

А, ну да

Нет. Язык запросов разрабатывался не для того, чтобы выдавать сырые данные огромного размера. Делать "ВЫБРАТЬ * ИЗ РегистрБухгалтерии.Хозрасчетный" и переборка выборки - еще более неверно, чем выгрузка в ТЗ.

по ком тянем в соседнюю базу данные например. Достаточно удобно запрос выгрузить в тз, тз в строку из строки и вот у вас тз на той стороне.

Кто тебе сказал, что 20 млн это сырые данные? Самая настоящая выжимка того что надо

язык-то может и разрабатывался так, но вот только изобретатели всяких форм отчетности типа алкогольной об этом не в курсе, по этому выборки в миллионы строк таки иногда бывают

из на клиенте в принципе есть, Грувви.

а вот этого делать нельзя.

Согласен с тем что это нужно делать порционо и желательно много поточно.

Не факт, что будет быстрее, а код усложняет....

почему??

Отличнейшее решение, что оно вам не нравится? Сериализация-десериализация позволяет избавиться от кучи проблем типа плавающей точки при передаче рублей.

Не понял, что хотел ты сказать. А так да: в обычных формах ТЗ можно сформировать на клиенте и там с ним работать. О сколько нам открытий чудных, готовит просвещения дух! Но это явно не тот случай.

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

+ при чем - два раза разместить, ведь ее же потом передают из процесса в процесс

Прерву вашу баталию, миллионы строк вполне живут в ТЗ на сервере и робят Если у фирмы миллионы строк, пусть ставят хороший сервер

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

Ну и че? ))) пусть хоть переварачивает сервер, от этого он не помрет и отработает.... Я открою секрет, то даже гото можно использовать.

На сколько я помню, 1С говорила, что на хард может упасть результат запроса, а не ТЗ.

А с МайкроСофтом они об этом договорились?

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

а что, у браузеров нет кешей? ;)

думаете там по одной строке передается? По идее по 5-10 тыс строк должно сразу в одной порции.

А разве не в буферном пуле СУБД хранится таблица значений?)

а что разве в них не чего не хранится??

2 если мы ее помещаем в параметр запроса для ВТ? наверное да, в нем