К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

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

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

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

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

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

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



Гость
1 - 09.09.2016 - 13:16
У меня дебуг включен. Если запустишь 2 экземпляра одной версии сервера предприятия в одной ОС, сообщи, плз, как ты это сделал.
Uho
2 - 09.09.2016 - 14:31
1-iMoxa > дык по ссылке же написано, не?
Гость
3 - 09.09.2016 - 14:45
(2) а у тебя сколько пользователей что ожидаешь тормозов от дебаг?
Гость
4 - 09.09.2016 - 14:51
(2) Хз. Раньше у 1С четко было прописано, что нельзя 2 экземпляра одного релиза на одном компе запустить.
Uho
5 - 09.09.2016 - 14:52
3-angro > допустим, около 70-80
Гость
6 - 09.09.2016 - 15:07
(5) ну вот сейчас где-то 200 пользователей, работает с дебагом, понятно пока опытная эксплуатация идёт, как сдадут систему, выключат. ну если и тормозит то не критично
Uho
7 - 09.09.2016 - 15:27
6-angro > эээ.. нигде же не описаны количественные характеристики замедления работы с ключом -debug
Как то неправильно это...

Еще вариант: разработку вести на локально-файловой, а на рабочей клиент-серверной -debug включать по мере необходимости.
Тоже как-то кривовато...
Гость
8 - 09.09.2016 - 16:45
А зачем тебе идеально сферическое отсутствие тормозов в вакууме?
Тебе за это зарплату больше дадут?
Включай дебуг и работай. Ничего не случится. Да и какие это нафиг тормоза, замедление на 5 миллисекунд?
Тормоза - это когда пользователи прибегают в слезах, у них документ проводится полторы минуты, отчёт строится 15 минут. Вот это да, тормоза.
Гость
9 - 09.09.2016 - 16:52
(8) От ситуации зависит. Могут потом при любых тормозах стрелы переводить на дебуг.
Гость
10 - 09.09.2016 - 17:05
При тормозах стрелы обычно переводят на программиста
И всем уже пофиг, какой там дебаг шмибаг
Гость
11 - 09.09.2016 - 17:07
Ещё раз: дебаг даёт задержку в миллисекунды
Совершенно не ощутимую обычными органами чувств.
Если система жестоко тормозит, нужно руки выпрямлять тому, кто писал код, а не на дебаг кивать.
Гость
12 - 09.09.2016 - 17:28
11-Мэри Сью > Руки - это больно.
Uho
13 - 09.09.2016 - 17:37
Цитата:
Сообщение от Мэри Сью Посмотреть сообщение
дебаг даёт задержку в миллисекунды
вот это и хотел выяснить, ибо (7)
Гость
14 - 09.09.2016 - 19:27
Безумие и отвага! Давай, жги, врубай отладку в продукте! Это ведь так весело - замедлить абсолютно все.

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

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

Всего вам доброго.
Гость
15 - 09.09.2016 - 20:41
Это, пожалуй, самый странный способ сублимации, который я встречала
Гость
16 - 10.09.2016 - 12:45
Цитата:
Сообщение от Reaper Посмотреть сообщение
Таким образом в продуктовой среде мы получаем рассинхронизацию метаданных на разных рабочих процессах. А это уже ведет к плавающим глюкам - у одного документ открывался 2 минуты а у другого мгновенно.
Это сколько кода нужно дописать то?
Цитата:
Сообщение от Reaper Посмотреть сообщение
Отдельную пикантность в связи с этим приобретут демонические обновления, ведь теперь при переносе сеансов между рабочими процессами получить разные версии метаданных становится очень просто.
Можно поподробнее про перенос сеансов между рабочими процессами?
Гость
17 - 10.09.2016 - 16:03
Цитата:
Сообщение от iMoxa Посмотреть сообщение
Это сколько кода нужно дописать то?
Безразлично
Цитата:
Сообщение от iMoxa Посмотреть сообщение
Можно поподробнее про перенос сеансов между рабочими процессами?
http://its.1c.ru/db/v83doc#bookmark:cs:TI000000037
Гость
18 - 10.09.2016 - 17:42
(17) Спасибо за ссылку.
Гость
19 - 13.09.2016 - 10:30
14-Reaper > Интересные рассуждения, но логика мне не до конца понятна.
"Рабочий процесс при обработке нового соединения копошится у себя в памяти и ищет загруженную конфигурацию, если не находит - загружает ее из БД."
Почему из этого следует вывод о паразитных нагрузках?
Единственное, что я вижу - rphost будет держать несколько разных конфигураций в памяти, если на этом сервере крутится несколько разных БД. Если памяти достаточно - в чем проблема?

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

"при переносе сеансов между рабочими процессами получить разные версии метаданных становится очень просто. " - разве 1С за этим не следит? Например, штатная ситуация - процессы перезапускаются через определенное время и все сеансы перелезают на другой процесс - что здесь с рассинхронизацией метаданных? Каким образом это может усугубить debug?
Гость
20 - 13.09.2016 - 10:50
15-Мэри Сью > Милашка )
Гость
21 - 13.09.2016 - 10:51
По теме: наблюдал как сервер начинает аварийно падать после включения debug, такое бывает. В общем - дебажить сервер можно, но только озираясь и испуганно вздрагивая.

Отредактировано Пудель; 13.09.2016 в 10:51. Причина: гав
Гость
22 - 13.09.2016 - 22:06
Цитата:
Сообщение от android Посмотреть сообщение
Почему из этого следует вывод о паразитных нагрузках?
Потому, что с бухгалтерией и зарплатой работает несравнимо меньше людей, чем с основной системой, а распределение пользователей по рабочим процессам контролю не поддается. В итоге ты никогда не угадаешь когда балансировщик начнет жонглировать сеансами, перебрасывая их между рабочими процессами, тем самым заставляя то выгружать, то загружать конфигурацию в память. И твое "достаточно памяти" станет питательной средой для фрагментации.
И да, особенности работы с памятью это не единственная причина для выселения БП и ЗУП подальше. Читай оригинальное сообщение.
Цитата:
Сообщение от android Посмотреть сообщение
что имеется ввиду под рассинхронизацией?
А то, что на одном рабочем процессе загружены метаданные заказа покупателя и более ничего, а на другом - только заказа поставщику. И при переносе сеанса внезапно начинается дозагрузка недостающих метаданных. А вот какую из версий метаданных загрузит рабочий процесс - не знает никто. Думаю, даже разработчики не знают.

А вообще, я вас не понимаю. В документации ясно написано "не рекомендуется". Это банально означает, что если вы можете решить задачу без включения отладки в продуктовой среде - значит надо решать без отладки в продуктовой среде. Просчитать риски альтернативных решений можно. Просчитать риски отладки на продуктовой среде - невозможно. Так какого черта?
Гость
23 - 13.09.2016 - 22:59
кажется следующее поколение VZ подросло
Гость
24 - 13.09.2016 - 23:03
щас не про 1с

по моему в фильме секретный фарватер было "если в лоции написано не рекомендуется значит разрешено"
Uho
25 - 14.09.2016 - 15:23
14-Reaper > чё то я тебя не понял, по ссылке из (0) имеется в виду запуск двух агентов сервера. Разве это не решает описанных тобой проблем?
Гость
26 - 14.09.2016 - 19:27
25-Uho > Все правильно. Несколько экземпляров сервера 1С решают эти проблемы. У меня просто от количества постов об "успешном" использовании отладки в продуктовом окружении стул стремительно сгорел.
Гость
27 - 14.09.2016 - 21:49
Цитата:
Сообщение от Reaper Посмотреть сообщение
У меня просто от количества постов об "успешном" использовании отладки в продуктовом окружении стул стремительно сгорел
Ващет, успешно использую дебаг в боевой базе, и уже не один год. Тормозов нет, падений нет. Что я делаю не так?
P.S. А за стулом следи, налегай на овощи. Пиво и разнузданный секс тоже очень хорошо помогают нормализовать кишечник.
Гость
28 - 15.09.2016 - 11:34
Цитата:
Сообщение от Мэри Сью Посмотреть сообщение
разнузданный секс тоже очень хорошо помогают нормализовать кишечник
Откровенно ...
Гость
29 - 15.09.2016 - 11:39
Цитата:
Сообщение от iMoxa Посмотреть сообщение
Откровенно ...
А здесь, в отличии от ТВ, не предусмотрен рейтинг (+6,+12,+14,+16).
Гость
30 - 15.09.2016 - 11:42
(29) Покемонолов внутрицерковный тоже думал, что в интернетах можно все.
Гость
31 - 15.09.2016 - 11:43
+(30) И сразу заработал рейтинг +3.
Гость
32 - 15.09.2016 - 11:49
Цитата:
Сообщение от iMoxa Посмотреть сообщение
Покемонолов внутрицерковный тоже думал, что в интернетах можно все.
А причём здесь это?
Он "ловил в храме", ты сидишь на работе/дома/в кафе и просто читаешь/пишешь на форум. Форум подвергается цензуре только в рамках правил этого форума. Дома/на работе/в кафе - ты ни с кем не взаимодействуешь (не привлекаешь особого внимания, не пристаёшь...) сидя за терминалом/ноутом/и т.п. (и не бегаешь по залу внутри кафе...). Таким образом ны не нарушаешь внутренний порядок помещений.
Но мы отвлеклись.
Гость
33 - 15.09.2016 - 11:53
(32) Ловил в храме, а выложил в инете ;) .
34 - 15.09.2016 - 13:57
Цитата:
Сообщение от iMoxa Посмотреть сообщение
Ловил в храме, а выложил в инете ;) .
это были воцерковленные покемоны. их можно было ловить только с благословения благочинного.


К списку вопросов






Copyright ©, Все права защищены