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

(0) Размер базы при этом имеет значение только в том случае, если сохранение конфигурации связано с реструктуризацией. Тут всё будет зависеть от количества и размеров таблиц, которые надо реструктурировать.
Всё остальное будет зависеть от параметров компа и сети (если база в сети). Чем быстрей проц и диск (память меньше 8Гб не рассматриваем), тем быстрее откроется база.

А с какой целью интересуетесь?
Ну даст тебе опрос некую среднюю цифру. Например, 1 минута. Как ты с этим будешь жить?

(1) вопрос из серии какая у вас зарплата...

(0) Голосовалку еще прикрути, ага.

(1) ну вот у меня 4 минуты этот процесс занимает(без реструктуризации), это долго или это нормально?

до каких значений это можно улучшить?

(4) Это нельзя считать нормальным. Хотя часто бывает и хуже.

(6) понятно что это ненормально, но это ненормально конкретно в моей базе или вообще такая ерунда с разработкой в ERP?

(4) как страшно жить...Вы как с базой работаете, по РДП?

(8) по РДП

(0) а если не обновлять конфу, быстро заходит?

(7) ерунда такая есть. Массовый характер она имеет.

(9) А в сеансе что ты видишь по оперативе, сколько процессоров, сколько пользовательских сеансов и т.п. ?

(4) С ERP сейчас не работаю. И вообще редко сталкиваюсь. Но помнится, было значительно быстрее.
(5) Посмотрите параметры компа разработчика для EDT. https://edt.1c.ru/docs/intro/requirements.php
Сравните с параметром своего компа.
(7) А что такого особенного в вашей базе? Это отраслёвка с какими-нибудь защищенными модулями? Или в базе десяток расширений, подключаемых при старте? А может в базе не выключена куча фоновых обработчиков, выолняемых при начале работы (всяческие интернет-поддержки, проверяющие обновления, начальные страницы с данными о предприятии или задачами пользователю, какие-нибудь прочие доработанные обработчики).

(10) 14 секунд

(9) >>  по РДП.

Ну так спросите у админов РДП-сервера. Может вам там выделено 4Гб на сессию и порезаны все остальные возможные ресурсы, и одновременно на сервере сидит пара сотен пользователей, интенсивно работающих.

Конфу надо обновлять там же, где и сама база валяется, а не по сети.

(13) значит добавь оперативы.

У меня сразу было 8 гиг. Я плакал недели две. Сжалились. добавили до 12. Я затем опять плакал. Сейчас там 22 гига.

(16) а что так можно было!?)))

Если конфа под замком и с расширением, то еще можно. А так..

(17) угу.

Хотя начиналось все с того, что там (на этом дев-серваке) даже режим отладки до меня никто выпросить не мог или не хотел или им не нужно было.
А может разрабам было нужно так чтоб часов побольше вписывать в ЛУРВ-ы

(14) ну это отдельный сервер разработки с 128 Гб оперативы, у меня сейчас сеанс съел 17 Гб

(19) просто они считали, что отладка для слабаков, настоящие гуру, должны зрить в корень и сразу принимать верное решение!

(21) и, видимо, писать весь код за один раз без ошибок, запускать базу один раз проверить, и готово.

(19) Народ плюнул на тормоза и делает на своих ПК, а туда только изменения заливает

конкретных цифр так никто и не написал

(22) именно так, только суровые условия могут воспитать настоящих рембо 1с.

(24) у меня УТ11 запускается за считанные секунды после обновления. Но это тестовая база. На рабочей, может запускаться гораздо дольше, потому, что одновременно 40 человек пытаются зайти в базу, может даже минуту открываться)

(23) Вероятно, что так и было. Но скорей всего, что не на своих персональных ПК, а на, скажем так, локальных серваках разработчиков.
Там до меня внедрение было силами франчайзи, у которого в инфрастуктуру много вкладывают.

(20) >> это отдельный сервер разработки.

Вот и идите со своей проблемой к админам.
Может там сервер какой-нибудь совсем ватный с древним процом и дисками, на котором, кроме вас толпа разрабов сидит со своими конфигурациями и базами.
Отсюда ведь не видно.

(0) да уж, я в такие момент вспоминаю свой первый комп с 32 мб оперативки и компиляцию курсачей на делфи.

Тут на сервере полтерабайта оперативки и 100500 ядер - и все равно, сидишь ждешь как голодный студент

(28) Так они говорят что это ваша 1С тормозит, а у нас вообще даже ничего не загружено.

Вот веб-разработке красота - сохраняешь файлик - в браузере сразу результат

(31) сохраняйте код в файлик и "выполнить", будет такая же "красота"))

вот я и хочу понять это реально платформа с конфигурацией ERP и базой на 600 Гб так мендленно работает или есть куда оптимизировать.

(32) есть пример?

(33) пустышка ЕРП столько же времени отрабатывает?

(34) КД2 посмотрите

(33) х.з. на самом деле, куда там и что получится оптимизировать...

если ты сам пишешь, что старт из конфигуратора при отстуствии перезаписи конфы проскакивает за 14 секунд.

(33) это платформа. это 1с, детка

(33) СУБД какая ? и Опять же число активных сеансов, число процев на серваке, сколько памяти выжрала СУБД - как так получается, что сеанс 17 гиг скушал, о каком сеансе речь?

(32) да уж иногда приходится в обработке пилить то, что потом надо перенести в документ

(24) 2 минуты. Работаю удаленно по ремоут апп, прямого доступа к серверам не имею, поэтому без понятия о их конфигурации и кол-ве разрабов на них трудящихся.

(41) ЕРП 2.4

нужен проц i9 4.5 ГГц чтоб хоть как то ворочалось

если реструктуризации не нужно, то можно держать открытый сеанс и делать динамику

(44) Динамическое обновление? Возможно так будет быстрее, надо попробовать.

(45) надеюсь вы сможете оперативно развернуть бекап в случае чего, и простой организации окупится скоростью ваших обновлений)

(46)  Но при чем здесь простой, когда речь про базу разработки

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

(45) самое быстрое - это разрабатывать в расширении и юзать динамическое обновление.
в конце все переносить

(49) зачем нужно динамическое обновление, если разрабатывать в расширении?

(49) (50) >> разрабатывать в расширении и юзать динамическое обновление.

Подключение/обновление расширения в продуктивной базе - это тоже самое, что и обычное динамическое обновление конфигурации.
Мы как-то словивили ошибку формата потока после обновления расширения в продуктивной базе (основную конфу никто не трогал). После этого делать так перестали.

(44) >> держать открытый сеанс и делать динамику.

И какой в этом смысл?
В открытых сеансах конфигурация не обновляется. А только появляется навязчивое всплывающее окно с рекомендацией перезапустить сеанс. Ну перезапустит он сеанс и будет ждать те же 4 минуты.

Мой результат - 87 секунд
Но, естественно, разработка только в расширении.

(44) (45) хахахах смешно ....

(51) (52) Вам надо поговорить с вашим психологом насчет расширенофобии.

(24) 6 минут

(52) но зачем его перезапускать?

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

(55) А при чем тут это?
Расширения используем. И довольно активно.
Разработку ведём и в основной конфе и в расширениях (в зависимости от задач и особенностей).
Но глюки, когда расширение у кого-то из пользователей подключилось, а у кого-то нет, ловим регулярно. Лишний раз заниматься танцами с чистками кешей времени нет. Поэтому в продуктиве любые изменения конфигурации, включая отключение/подключение/обновление расширений только в офлайне. Так всем спокойней.

(57) >> зачем его перезапускать?

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

(60) нужно запускать доп сеанс не из конфигуратора и его не трогать

(61) Ах вот ты о чём. Ну возможно. Честно говоря, не пробовал. Прокатить такое, наверное, может. Но только с расширениями.
Будет расти справочник ВерсииРасширений и связанные регистры, если перезапускать слишком часто. Но это не критично, если в базе никто больше не сидит. А вот если в базе работают пользователи и некоторые любят запускать по несколько сеансов одновременно, можно легко получить ситуацию, когда у одного пользователя в нескольких запущенных в разное время сеансах разные версии расширений. На продуктиве я бы точно такого делать не стал.

(61) и что ты в нем увидишь? .... или хочешь динамически все время обновляться? что по идее не безопасно

(62) расширения - это перпендикулярное условие. можно с ними и без

(63) в тот сеанс смотреть не нужно. ты продолжаешшь работать как и обычно со своим сеансом из конфигуратора

(24) локальная файловая ЕРП - 45 сек

(61) попробовал - еще дольше получается на 1.5 мин. Какое ускорение наблюдали на практике?

Чтобы быстро разрабатывать
1) Делать это в расширениях
2) В фоне висит устаревший сеанс пользователя
3) Регулярно чистить кеш AppData\Local\1C\1cv8
4) Тупо рубить rphost сервера разработки, который выжрал за 15Гб, когда ты уверен, что никто не обновляет, либо ты один на нем.

(67) дольше повторный запуск или первый?

(68) сурово

(67) Это ты про расширение или основную конфу?

(68) А если делать на файловой на каком-нибудь ай-девятом и нулевым рейдом из пары nvme SSD?

(68) кстати про (4) а в чем проблема?

(73) за 4 минуты выходишь из потока

(72) Я уже УТ11 то в конце стеснялся разрабатывать на файловой, когда у меня один раз умерла конфа и мне пришлось ее через toolcd выковыривать, а уж ERP точно нет.

(75) Предлагают разрабатывать на копии в файловом варианте на локальной быстрой машине, а результат уже просто переносить на дев сервер.
Этот вариант был бы идеальным, но копировать 600 Gb...

(76) конфиг в ЕРП уже 600 ГБ?

Тормоза-тормоза... :) Вот у меня тормоза - конфигуратор ERP по RDP 45 минут открывался...

(76) Разнеси сервер приложений и сервер СУБД, и клонируешь базу в копию и работаешь в ней а потом переносишь!
А по теме ERP это сверх тормоз по обновлению в клиент-серверном режиме, скорее всего связано с объемом конфигурации. Слишком долго его кеш сервер приложений обновляет у себя.
Если работать с расширением то тут проще и быстрее, но опять же если не затрагивает данные!

(71) конфа

(68)В расширении разрабатывать тоже не вариант - реквизиты добавленные в расширение, невозможно выбрать конструктором запроса в конфигураторе - а писать запрос вручную - не всегда удобно когда он из нескольких запросов.

(81) писать удобнее в консоли в режиме Предприятия, там и данные есть