Отладка серверного кода в клиент-серверном варианте
 

Коллеги, что-то я подзапямятовал или и не знал (?), как происходит отладка серверного кода управляемого приложения в клиент-серверном варианте?

Запускаем агент сервера с ключом debug и по ЖКК получаем

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

а как вы отлаживаете тестовые базы при условии, что лицензия на сервер 1С:Предприятия одна?

Нашел ссылку [url]http://infostart.ru/public/125933/[/url], там говорится, что запускают две службы агента сервера со всеми вытекающими. Проще никак?

У меня дебуг включен. Если запустишь 2 экземпляра одной версии сервера предприятия в одной ОС, сообщи, плз, как ты это сделал.

1-iMoxa > дык по ссылке же написано, не?

(2) а у тебя сколько пользователей что ожидаешь тормозов от дебаг?

(2) Хз. Раньше у 1С четко было прописано, что нельзя 2 экземпляра одного релиза на одном компе запустить.

3-angro > допустим, около 70-80

(5) ну вот сейчас где-то 200 пользователей, работает с дебагом, понятно пока опытная эксплуатация идёт, как сдадут систему, выключат. ну если и тормозит то не критично

6-angro > эээ.. нигде же не описаны количественные характеристики замедления работы с ключом -debug
Как то неправильно это...

Еще вариант: разработку вести на локально-файловой, а на рабочей клиент-серверной -debug включать по мере необходимости.
Тоже как-то кривовато...

А зачем тебе идеально сферическое отсутствие тормозов в вакууме?
Тебе за это зарплату больше дадут?
Включай дебуг и работай. Ничего не случится. Да и какие это нафиг тормоза, замедление на 5 миллисекунд?
Тормоза - это когда пользователи прибегают в слезах, у них документ проводится полторы минуты, отчёт строится 15 минут. Вот это да, тормоза.

(8) От ситуации зависит. Могут потом при любых тормозах стрелы переводить на дебуг.

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

Ещё раз: дебаг даёт задержку в миллисекунды
Совершенно не ощутимую обычными органами чувств.
Если система жестоко тормозит, нужно руки выпрямлять тому, кто писал код, а не на дебаг кивать.

11-Мэри Сью > Руки - это больно.

[quote=Мэри Сью;42877668]дебаг даёт задержку в миллисекунды[/quote]вот это и хотел выяснить, ибо (7)

Безумие и отвага! Давай, жги, врубай отладку в продукте! Это ведь так весело - замедлить абсолютно все.

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

Теперь про debug. Он имеет две задачи - включить собственно отладку, т.е. процесс перехвата любой строки кода конфигурации, и уменьшить задержки программиста на перезапусках приложения. Ради отладки система замедляет работу [b]каждой строки[/b] конфигурации. Кстати, это привело к появлению мифа о том, что код, записанный в одну строку, работает быстрее, чем нормально оформленный. Этот же миф легко позволяет оценить потери на включении отладки. Ну и чем больше строк кода используется при обработке действия пользователя - тем заметнее тормоза. Ради ускорения перезапуска - применяется режим отложенной загрузки метаданных. Т.е. с этим флагом рабочий процесс держит в памяти только ту часть конфигурации к которой уже обращался. Платформа 8.3 управляет количеством рабочих процессов самостоятельно, и стремится, как правило, использовать больше одного процесса. Таким образом в продуктовой среде мы получаем рассинхронизацию метаданных на разных рабочих процессах. А это уже ведет к плавающим глюкам - у одного документ открывался 2 минуты а у другого мгновенно. Фактически debug переводит сервер в режим оптимизации работы для единственного пользователя-разработчика, когда работа в многопользовательском режиме становится нестабильной с точки зрения производительности. Отдельную пикантность в связи с этим приобретут демонические обновления, ведь теперь при переносе сеансов между рабочими процессами получить разные версии метаданных становится очень просто. При этом известная политика 1С следить за уникальностью идентификаторов в пределах одной базы привела однажды к тому, что динамическое обновление одной базы на тестовом сервере разрушило метаданные другой.

Всего вам доброго.

Это, пожалуй, самый странный способ сублимации, который я встречала

[quote=Reaper;42878292]Таким образом в продуктовой среде мы получаем рассинхронизацию метаданных на разных рабочих процессах. А это уже ведет к плавающим глюкам - у одного документ открывался 2 минуты а у другого мгновенно.[/quote]Это сколько кода нужно дописать то?[quote=Reaper;42878292]Отдельную пикантность в связи с этим приобретут демонические обновления, ведь теперь при переносе сеансов между рабочими процессами получить разные версии метаданных становится очень просто. [/quote]Можно поподробнее про перенос сеансов между рабочими процессами?

[quote=iMoxa;42880642]Это сколько кода нужно дописать то?[/quote]
Безразлично
[quote=iMoxa;42880642]Можно поподробнее про перенос сеансов между рабочими процессами?[/quote]
[url]http://its.1c.ru/db/v83doc#bookmark:cs:TI000000037[/url]

(17) Спасибо за ссылку.

14-Reaper > Интересные рассуждения, но логика мне не до конца понятна.
"Рабочий процесс при обработке нового соединения копошится у себя в памяти и ищет загруженную конфигурацию, если не находит - загружает ее из БД."
Почему из этого следует вывод о паразитных нагрузках?
Единственное, что я вижу - rphost будет держать несколько разных конфигураций в памяти, если на этом сервере крутится несколько разных БД. Если памяти достаточно - в чем проблема?

Про второй абзац:
" в продуктовой среде мы получаем рассинхронизацию метаданных на разных рабочих процессах" - что имеется ввиду под рассинхронизацией? Разные пользователи работают с разными версиями модулей и форм? Так вроде это обычное поведение после динамического обновления, как на это влияет debug?

"при переносе сеансов между рабочими процессами получить разные версии метаданных становится очень просто. " - разве 1С за этим не следит? Например, штатная ситуация - процессы перезапускаются через определенное время и все сеансы перелезают на другой процесс - что здесь с рассинхронизацией метаданных? Каким образом это может усугубить debug?

15-Мэри Сью > Милашка )

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

[quote=android;42894799]Почему из этого следует вывод о паразитных нагрузках?[/quote]
Потому, что с бухгалтерией и зарплатой работает несравнимо меньше людей, чем с основной системой, а распределение пользователей по рабочим процессам контролю не поддается. В итоге ты никогда не угадаешь когда балансировщик начнет жонглировать сеансами, перебрасывая их между рабочими процессами, тем самым заставляя то выгружать, то загружать конфигурацию в память. И твое "достаточно памяти" станет питательной средой для фрагментации.
И да, особенности работы с памятью это не единственная причина для выселения БП и ЗУП подальше. Читай оригинальное сообщение.
[quote=android;42894799]что имеется ввиду под рассинхронизацией?[/quote] А то, что на одном рабочем процессе загружены метаданные заказа покупателя и более ничего, а на другом - только заказа поставщику. И при переносе сеанса внезапно начинается дозагрузка недостающих метаданных. А вот какую из версий метаданных загрузит рабочий процесс - не знает никто. Думаю, даже разработчики не знают.

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

кажется следующее поколение VZ подросло

щас не про 1с

по моему в фильме секретный фарватер было "если в лоции написано не рекомендуется значит разрешено"

14-Reaper > чё то я тебя не понял, по ссылке из (0) имеется в виду запуск двух агентов сервера. Разве это не решает описанных тобой проблем?

25-Uho > Все правильно. Несколько экземпляров сервера 1С решают эти проблемы. У меня просто от количества постов об "успешном" использовании отладки в продуктовом окружении стул стремительно сгорел.

[quote=Reaper;42904945]У меня просто от количества постов об "успешном" использовании отладки в продуктовом окружении стул стремительно сгорел[/quote]
Ващет, успешно использую дебаг в боевой базе, и уже не один год. Тормозов нет, падений нет. Что я делаю не так?
P.S. А за стулом следи, налегай на овощи. Пиво и разнузданный секс тоже очень хорошо помогают нормализовать кишечник.

[quote=Мэри Сью;42905696]разнузданный секс тоже очень хорошо помогают нормализовать кишечник[/quote]Откровенно ...

[quote=iMoxa;42908265]Откровенно ...[/quote]
А здесь, в отличии от ТВ, не предусмотрен рейтинг (+6,+12,+14,+16).

(29) Покемонолов внутрицерковный тоже думал, что в интернетах можно все.

+(30) И сразу заработал рейтинг +3.

[quote=iMoxa;42908328]Покемонолов внутрицерковный тоже думал, что в интернетах можно все. [/quote]
А причём здесь это?
Он "ловил в храме", ты сидишь на работе/дома/в кафе и просто читаешь/пишешь на форум. Форум подвергается цензуре только в рамках правил этого форума. Дома/на работе/в кафе - ты ни с кем не взаимодействуешь (не привлекаешь особого внимания, не пристаёшь...) сидя за терминалом/ноутом/и т.п. (и не бегаешь по залу внутри кафе...). Таким образом ны не нарушаешь внутренний порядок помещений.
Но мы отвлеклись.

(32) Ловил в храме, а выложил в инете ;) .

[quote=iMoxa;42908409]Ловил в храме, а выложил в инете ;) .[/quote]
это были воцерковленные покемоны. их можно было ловить только с благословения благочинного.